* set_par/check-var vs. fbcon
@ 2003-10-28 22:19 Benjamin Herrenschmidt
2003-10-29 9:37 ` Geert Uytterhoeven
0 siblings, 1 reply; 6+ messages in thread
From: Benjamin Herrenschmidt @ 2003-10-28 22:19 UTC (permalink / raw)
To: James Simmons; +Cc: Linux Fbdev development list
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: set_par/check-var vs. fbcon
2003-10-28 22:19 set_par/check-var vs. fbcon Benjamin Herrenschmidt
@ 2003-10-29 9:37 ` Geert Uytterhoeven
2003-10-29 22:09 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 6+ messages in thread
From: Geert Uytterhoeven @ 2003-10-29 9:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: James Simmons, Linux Fbdev development list
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/
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: set_par/check-var vs. fbcon
2003-10-29 9:37 ` Geert Uytterhoeven
@ 2003-10-29 22:09 ` Benjamin Herrenschmidt
2003-10-29 22:39 ` James Simmons
0 siblings, 1 reply; 6+ messages in thread
From: Benjamin Herrenschmidt @ 2003-10-29 22:09 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: James Simmons, Linux Fbdev development list
> 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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: set_par/check-var vs. fbcon
2003-10-29 22:09 ` Benjamin Herrenschmidt
@ 2003-10-29 22:39 ` James Simmons
2003-10-30 1:16 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 6+ messages in thread
From: James Simmons @ 2003-10-29 22:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Geert Uytterhoeven, Linux Fbdev development list
> > 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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: set_par/check-var vs. fbcon
2003-10-29 22:39 ` James Simmons
@ 2003-10-30 1:16 ` Benjamin Herrenschmidt
2003-10-30 9:16 ` Geert Uytterhoeven
0 siblings, 1 reply; 6+ messages in thread
From: Benjamin Herrenschmidt @ 2003-10-30 1:16 UTC (permalink / raw)
To: James Simmons; +Cc: Geert Uytterhoeven, Linux Fbdev development list
> 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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: set_par/check-var vs. fbcon
2003-10-30 1:16 ` Benjamin Herrenschmidt
@ 2003-10-30 9:16 ` Geert Uytterhoeven
0 siblings, 0 replies; 6+ messages in thread
From: Geert Uytterhoeven @ 2003-10-30 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: James Simmons, Linux Fbdev development list
On Thu, 30 Oct 2003, Benjamin Herrenschmidt wrote:
> > 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/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-10-30 9:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-10-28 22:19 set_par/check-var vs. fbcon Benjamin Herrenschmidt
2003-10-29 9:37 ` Geert Uytterhoeven
2003-10-29 22:09 ` Benjamin Herrenschmidt
2003-10-29 22:39 ` James Simmons
2003-10-30 1:16 ` Benjamin Herrenschmidt
2003-10-30 9:16 ` Geert Uytterhoeven
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).