From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-10-28 22:22:10
Hi !
I'm having a problem getting proper semantics for set_par/check_var
calls with 2.6 in radeonfb.
So far, I assumed they would be called with a complete structure
containing mode timings etc... though check_var() would eventually
fail if not supported and/or slightly "adapt" the var.
That is the behaviour that is needed for things like MacOnLinux
(or even XFree on top of fbdev) to work properly.
However, when stty is used, the fbcon code will call these with
a var which is the current one with only the size changed. That
is it asks for a mode with a different size, but the timings of
the previous one. This doesn't work properly with radeonfb, and
I wonder if there is one fbdev that has this working properly
at all...
For such thing, we need to pick a full mode (timings included)
that matches the new size... So the semantics expected by the
call issued from fbcon are more like "pick a mode that has this
size", though the timings in there are a "hint" to eventually
pick a mode that has the same vfreq...
I wonder... maybe we shall set a specific flag when doing that
set_var call from fbcon to trigger the intended mecanism. Or
should we have all check_var()/set_par() calls in drivers
implement a mecanism by default ? That would prevent userland
from using the ioctl to change the timings precisely though...
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
On Wed, 29 Oct 2003, Benjamin Herrenschmidt wrote:
I'm having a problem getting proper semantics for set_par/check_var
calls with 2.6 in radeonfb.
So far, I assumed they would be called with a complete structure
containing mode timings etc... though check_var() would eventually
fail if not supported and/or slightly "adapt" the var.
That is the behaviour that is needed for things like MacOnLinux
(or even XFree on top of fbdev) to work properly.
However, when stty is used, the fbcon code will call these with
a var which is the current one with only the size changed. That
is it asks for a mode with a different size, but the timings of
the previous one. This doesn't work properly with radeonfb, and
I wonder if there is one fbdev that has this working properly
at all...
For such thing, we need to pick a full mode (timings included)
that matches the new size... So the semantics expected by the
call issued from fbcon are more like "pick a mode that has this
size", though the timings in there are a "hint" to eventually
pick a mode that has the same vfreq...
I wonder... maybe we shall set a specific flag when doing that
set_var call from fbcon to trigger the intended mecanism. Or
should we have all check_var()/set_par() calls in drivers
implement a mecanism by default ? That would prevent userland
from using the ioctl to change the timings precisely though...
Can't fbcon/stty create a var for the specified resolution from the
modedb/gttf?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-10-29 22:10:27
Can't fbcon/stty create a var for the specified resolution from the
modedb/gttf?
Actually, I'd prefer my driver to create a var from the width/height/freq,
especially since I've brought in EDID stuff, as my driver is the one who
knows what modes are really useable on the monitor. Or maybe, create an
"official" way for the driver to expose the modedb it created to fbcon...
This is even more true with iMacs & their fixed -hfreq monitor. I've not
'fixed' that yet, but ultimately, the driver will have a specific modedb
as well for the display.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
From: James Simmons <hidden> Date: 2003-10-29 22:39:28
quoted
Can't fbcon/stty create a var for the specified resolution from the
modedb/gttf?
Actually, I'd prefer my driver to create a var from the width/height/freq,
especially since I've brought in EDID stuff, as my driver is the one who
knows what modes are really useable on the monitor. Or maybe, create an
"official" way for the driver to expose the modedb it created to fbcon...
This is even more true with iMacs & their fixed -hfreq monitor. I've not
'fixed' that yet, but ultimately, the driver will have a specific modedb
as well for the display.
We have the ability to create a var based on height, width and another
variable. When we lack EDID data we use the GTF formulas. The function for
this is fb_get_mode in fbmon.c. Now when we do have EDID info we use the function.
For this we have fb_get_monitor_limits.
The monitor info is very important. It is used to validate or invalidate a mode.
The next set of functions that are important are:
fb_validate_mode -> Used in all cases. Validates a var.
fb_create_modedb
fb_destroy_modedb
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-10-30 01:17:28
We have the ability to create a var based on height, width and another
variable. When we lack EDID data we use the GTF formulas. The function for
this is fb_get_mode in fbmon.c. Now when we do have EDID info we use the function.
For this we have fb_get_monitor_limits.
The monitor info is very important. It is used to validate or invalidate a mode.
The next set of functions that are important are:
fb_validate_mode -> Used in all cases. Validates a var.
fb_create_modedb
fb_destroy_modedb
Well, I know we have those functions, but that doesn't help me
about how we shall use them. Specifically in radeonfb where I
do have the modedb based on EDID at hand (provided I could probe
it, if not, I want to default to the std VESA modes, not some
GTF formula).
The point I'm trying to make is that we are on one side called with
only width/height valid basically (by fbcon) or with a full mode with
timings (from userland ioctl). How do we choose what to do ? Also
userland may want to use our ability to "calculate" a mode based
only on H/W, or may want us to pick one with H/W and a freq, or may
provide us with a full mode with all timings in there. There is
currently no way to make a difference from within the driver on what
data in the passed in "var" are actually to be used to make the
actual mode.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
On Thu, 30 Oct 2003, Benjamin Herrenschmidt wrote:
quoted
We have the ability to create a var based on height, width and another
variable. When we lack EDID data we use the GTF formulas. The function for
this is fb_get_mode in fbmon.c. Now when we do have EDID info we use the function.
For this we have fb_get_monitor_limits.
The monitor info is very important. It is used to validate or invalidate a mode.
The next set of functions that are important are:
fb_validate_mode -> Used in all cases. Validates a var.
fb_create_modedb
fb_destroy_modedb
Well, I know we have those functions, but that doesn't help me
about how we shall use them. Specifically in radeonfb where I
do have the modedb based on EDID at hand (provided I could probe
it, if not, I want to default to the std VESA modes, not some
GTF formula).
The point I'm trying to make is that we are on one side called with
only width/height valid basically (by fbcon) or with a full mode with
timings (from userland ioctl). How do we choose what to do ? Also
userland may want to use our ability to "calculate" a mode based
only on H/W, or may want us to pick one with H/W and a freq, or may
provide us with a full mode with all timings in there. There is
currently no way to make a difference from within the driver on what
data in the passed in "var" are actually to be used to make the
actual mode.
If (when) we convert fbdev to use sysfs instead of ioctls, we can have a magic
file in which you `cat' your var, and another one for `simple' mode specifiers
(cfr. the modedb parameter <width>x<height>[-depth][@refresh]).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/