linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] Some questions

[Sven L. <lu...@dp...>]

On Thu, Mar 06, 2003 at 06:51:58PM +0800, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 18:48, Antonino Daplas wrote:
> > On Thu, 2003-03-06 at 18:31, Sven Luther wrote:
> > > On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> > > > Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> > > > calculate hsync and vsync.  Compare this with your monitor's limit -- if
> > > > any fall outside, the entire mode, pixelclock and all is not valid.
> > > > 
> > > > (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> > > > 
> > > > And if you use very narrow vsync and hsync ranges, then the "stale"
> > > > pixelclock will always most certainly be invalid.
> > > 
> > > BTW, do we have an easy way of knowing if it is an LCD or analog monitor
> > > which is attached to the card (or even a TV) ? I think the radeonfb
> > > knows how to do this, not sure though.
> > > 
> > 
> > There's an EDID parser in fbmon.c.  I think it will work only for the
> > PPC. This is currently used by rivafb and radeonfb. For the rest, either

Mmm, is it because the EDID parser uses the EDID information pased by
the OF ?

> > we implement DDC or just have something similar to XF86Config's
> > HorizSync and VertRefresh.  We can load this either as a kernel/module
> > option or passed via ioctl/sysfs.  

Most monitors today have DDC support, so i guess best would be to use
it, and fall back to a command line option if DDC is not supported.

> > I'm already doing this with the i810fb (as boot/module option), which
> > greatly simplified mode switching.
> 
> Oops, totally missed your question :-)  But yes, I think the EDID block
> contains information about the monitor type, not sure thogh.

X finds :

Digital Display Input

So, i guess this is it.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 18:48, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 18:31, Sven Luther wrote:
> > On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> > > Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> > > calculate hsync and vsync.  Compare this with your monitor's limit -- if
> > > any fall outside, the entire mode, pixelclock and all is not valid.
> > > 
> > > (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> > > 
> > > And if you use very narrow vsync and hsync ranges, then the "stale"
> > > pixelclock will always most certainly be invalid.
> > 
> > BTW, do we have an easy way of knowing if it is an LCD or analog monitor
> > which is attached to the card (or even a TV) ? I think the radeonfb
> > knows how to do this, not sure though.
> > 
> 
> There's an EDID parser in fbmon.c.  I think it will work only for the
> PPC. This is currently used by rivafb and radeonfb. For the rest, either
> we implement DDC or just have something similar to XF86Config's
> HorizSync and VertRefresh.  We can load this either as a kernel/module
> option or passed via ioctl/sysfs.  
> 
> I'm already doing this with the i810fb (as boot/module option), which
> greatly simplified mode switching.
> 

Oops, totally missed your question :-)  But yes, I think the EDID block
contains information about the monitor type, not sure thogh.

Tony

Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 18:31, Sven Luther wrote:
> On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> > Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> > calculate hsync and vsync.  Compare this with your monitor's limit -- if
> > any fall outside, the entire mode, pixelclock and all is not valid.
> > 
> > (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> > 
> > And if you use very narrow vsync and hsync ranges, then the "stale"
> > pixelclock will always most certainly be invalid.
> 
> BTW, do we have an easy way of knowing if it is an LCD or analog monitor
> which is attached to the card (or even a TV) ? I think the radeonfb
> knows how to do this, not sure though.
> 

There's an EDID parser in fbmon.c.  I think it will work only for the
PPC. This is currently used by rivafb and radeonfb. For the rest, either
we implement DDC or just have something similar to XF86Config's
HorizSync and VertRefresh.  We can load this either as a kernel/module
option or passed via ioctl/sysfs.  

I'm already doing this with the i810fb (as boot/module option), which
greatly simplified mode switching.

Tony

Re: [Linux-fbdev-devel] Some questions

[Sven L. <lu...@dp...>]

On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> calculate hsync and vsync.  Compare this with your monitor's limit -- if
> any fall outside, the entire mode, pixelclock and all is not valid.
> 
> (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> 
> And if you use very narrow vsync and hsync ranges, then the "stale"
> pixelclock will always most certainly be invalid.

BTW, do we have an easy way of knowing if it is an LCD or analog monitor
which is attached to the card (or even a TV) ? I think the radeonfb
knows how to do this, not sure though.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 18:14, Geert Uytterhoeven wrote:
> On 6 Mar 2003, Antonino Daplas wrote:
> > On Thu, 2003-03-06 at 17:12, Geert Uytterhoeven wrote:
> > > What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
> > > current resolution?
> > > 
> > > If you use stty to change the number of cols/rows, or change the font, or use
> > > fbset, your text console may end up being smaller or larger than the real
> > > screen size, in which case margins are cleared, or columns/lines are lost.
> > > (Optionally, we can center the text console if it's smaller than the real
> > >  screen size.)
> > > 
> > 
> > Which is basically what stty does for the standard console (except that
> > lines are not lost, but wrapped, and margins are not cleared).
> > 
> > So, we need to reimplement the clipping code.
> 
> In fbcon, I hope?
> 

Yes, it's easier to do this in fbcon.

Tony

Re: [Linux-fbdev-devel] Some questions

[Geert U. <ge...@li...>]

On 6 Mar 2003, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 17:12, Geert Uytterhoeven wrote:
> > What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
> > current resolution?
> > 
> > If you use stty to change the number of cols/rows, or change the font, or use
> > fbset, your text console may end up being smaller or larger than the real
> > screen size, in which case margins are cleared, or columns/lines are lost.
> > (Optionally, we can center the text console if it's smaller than the real
> >  screen size.)
> > 
> 
> Which is basically what stty does for the standard console (except that
> lines are not lost, but wrapped, and margins are not cleared).
> 
> So, we need to reimplement the clipping code.

In fbcon, I hope?

> > IMHO this is the most orthogonal approach. Fbcon takes care of the text
> > console, fbdev takes care of the graphics hardware and the video mode. Both
> > parts do (try to) not influence each other.
> > 
> > Optionally, fbset can call stty to change the number of cols/rows, if the user
> > wants that.
> 
> Or even a simple script that basically does "fbset 1024x768-60 && stty
> cols 128 rows 48". Of course, adding this to fbset itself will make it
> transparent to the user.
> 
> Sounds very logical to me :-)

Yep ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

[Fwd: Re: [Linux-fbdev-devel] Some questions]

[Thomas W. <th...@wi...>]

-------- Original Message --------
Subject: Re: [Linux-fbdev-devel] Some questions
Date: Thu, 06 Mar 2003 10:30:21 +0100
From: Thomas Winischhofer <th...@wi...>
To: Geert Uytterhoeven <ge...@li...>
References: <Pin...@ve...>

Geert Uytterhoeven wrote:
 > What if fbcon implements a text console _on top of_ fbdev? I.e. it
 > uses the current resolution?
 >
 > If you use stty to change the number of cols/rows, or change the font,
 > or use fbset, your text console may end up being smaller or larger
 > than the real screen size, in which case margins are cleared, or
 > columns/lines are lost. (Optionally, we can center the text console if
 >  it's smaller than the real  screen size.)
 >
 > IMHO this is the most orthogonal approach. Fbcon takes care of the
 > text console, fbdev takes care of the graphics hardware and the video
 > mode. Both parts do (try to) not influence each other.
 >
 > Optionally, fbset can call stty to change the number of cols/rows, if
 > the user wants that.
 >
 > What do you think?

I think that sounds like the best solution, and it also respects the
fact that fbcon and fbdev are two different pairs of shoes.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...            http://www.winischhofer.net/

Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 17:43, Thomas Winischhofer wrote:
> > Mode checking is not simply looking at xres and yres, but also looking
> > at htotal, and vtotal to derive hsync, vsync and pixelclock.  These are
> > then compared to the monitor/graphics card's capability.  If any of the
> > values fall outside the limits then the mode is not valid.  Otherwise,
> > the new mode should still produce a usable display, perhaps not the one
> > the user wants (ie refresh rate is lower).  By this time though, the
> > user can freely use fbset to fine tune all the timings.
> 
> Perhaps I have not made myself clear:
> 
> I start with a default 800x600-60. Pixelclock in var is now X.
> 
> fbcon_resize adapts the xres and yres, leaving the pixelclock alone.
> 
> The driver sees upon the check_var call: xres, yres and X - the old 
> pixelclock (which is non-zero).
> 
> That pixelclock *COULD* be valid, but it COULD also be invalid! There is 
> no way of distinguishing!
> 

Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
calculate hsync and vsync.  Compare this with your monitor's limit -- if
any fall outside, the entire mode, pixelclock and all is not valid.

(see fb_get_mode() and fb_validate_mode() in fbmon.c)

And if you use very narrow vsync and hsync ranges, then the "stale"
pixelclock will always most certainly be invalid.

Tony

Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 17:12, Geert Uytterhoeven wrote:
> 
> What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
> current resolution?
> 
> If you use stty to change the number of cols/rows, or change the font, or use
> fbset, your text console may end up being smaller or larger than the real
> screen size, in which case margins are cleared, or columns/lines are lost.
> (Optionally, we can center the text console if it's smaller than the real
>  screen size.)
> 

Which is basically what stty does for the standard console (except that
lines are not lost, but wrapped, and margins are not cleared).

So, we need to reimplement the clipping code.

> IMHO this is the most orthogonal approach. Fbcon takes care of the text
> console, fbdev takes care of the graphics hardware and the video mode. Both
> parts do (try to) not influence each other.
> 
> Optionally, fbset can call stty to change the number of cols/rows, if the user
> wants that.
> 

Or even a simple script that basically does "fbset 1024x768-60 && stty
cols 128 rows 48". Of course, adding this to fbset itself will make it
transparent to the user.

Sounds very logical to me :-)

Tony

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

Antonino Daplas wrote:
> On Thu, 2003-03-06 at 16:49, Thomas Winischhofer wrote:
>>>However, the brokenness is really on the driver side.  They are unable
>>>to change the video mode unless they are supplied with the correct
>>>timing parameters where in fact they actually have the best knowledge on
>>>how to calculate them.  
>>
>>Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
>>requires at least x and y dimension AND A CLOCK (or a vertical refresh 
>>rate, which I would prefer).
> 
> The VESA GTF can calculate timings using only xres, yres and any of the
> three...
> 
> 1. desired pixelclock
> 2. desired refresh
> 3. desired hsync
> 
> ... all of which can be chosen by the driver, or extracted from the monitor
> (ie. DDC or uploaded by the user).

See? Need a clock! My word! :)

> Mode checking is not simply looking at xres and yres, but also looking
> at htotal, and vtotal to derive hsync, vsync and pixelclock.  These are
> then compared to the monitor/graphics card's capability.  If any of the
> values fall outside the limits then the mode is not valid.  Otherwise,
> the new mode should still produce a usable display, perhaps not the one
> the user wants (ie refresh rate is lower).  By this time though, the
> user can freely use fbset to fine tune all the timings.

Perhaps I have not made myself clear:

I start with a default 800x600-60. Pixelclock in var is now X.

fbcon_resize adapts the xres and yres, leaving the pixelclock alone.

The driver sees upon the check_var call: xres, yres and X - the old 
pixelclock (which is non-zero).

That pixelclock *COULD* be valid, but it COULD also be invalid! There is 
no way of distinguishing!

>>What about the following solution: What if fbcon_resize sets the clock 
>>in the var to 0? We could use this to force low level drivers to decide 
>>on the clock for themselves. Otherwise, ie if the clock field is 
>>non-zero, they are supposed to take it as the desired clock.
> 
> Yes, that's another solution.  Just invalidate the timings and force the
> driver to compute a modeline each time.

I think Geert came up with a better solution in the meantime.

But a general rule should be anyway: Whenever passing a var to the 
driver which only changed in a few fields and through this invalidated 
the timing settings, the caller should set everthing else to ZERO, in 
other words: invalidate it in a recognizable way. That's IMHO the only 
way the driver can distinguish between intended and unintended settings.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...            http://www.winischhofer.net/

Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 16:49, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> > fbcon_resize() is not that broken, it's only trying to do what it's
> > supposed to do.  It is indeed limited because it is trying to outguess
> > the low-level drivers on the best resolution for a window size.
> > 
> > However, the brokenness is really on the driver side.  They are unable
> > to change the video mode unless they are supplied with the correct
> > timing parameters where in fact they actually have the best knowledge on
> > how to calculate them.  
> 
> Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
> requires at least x and y dimension AND A CLOCK (or a vertical refresh 
> rate, which I would prefer).

The VESA GTF can calculate timings using only xres, yres and any of the
three...

1. desired pixelclock
2. desired refresh
3. desired hsync

... all of which can be chosen by the driver, or extracted from the monitor
(ie. DDC or uploaded by the user).

For non-GTF compatible monitors, you can choose any of the standard timings
table. 

> 
> The driver is supposed to handle the "var"s it's fed. If that var is 
> like the ones that result from the current fbcon_resize, namely with a 
> new x and y res, but no valid clock, how on earth should the driver do 
> this then? It receives a var which looks correct, and in fact, *could* 
> be correct sometimes:
> 

Mode checking is not simply looking at xres and yres, but also looking
at htotal, and vtotal to derive hsync, vsync and pixelclock.  These are
then compared to the monitor/graphics card's capability.  If any of the
values fall outside the limits then the mode is not valid.  Otherwise,
the new mode should still produce a usable display, perhaps not the one
the user wants (ie refresh rate is lower).  By this time though, the
user can freely use fbset to fine tune all the timings.

For fixed-frequency monitors or analog TV (where timings are critical),
you can use very strict operating limits (like vsync_min = 60 and
vsync_max = 60).  With strict limits, it's unlikely that the new timings
will be valid, so the driver will always be forced to calculate a new
mode.

> Suppose we have another application, say DirectFB, feeding the low level 
> drivers with complete and correct "var"s.
> 
> In both cases we have valid x any y resultions, and a non-zero clock field.
> 
> Should we then let the driver read the x and y resolution and forget 
> about the rest of that var? I hardly think that's what the public var is 
> for. It could be reduced to a struct { USHORT xres, USHORT yres } then.
> 
> > So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
> > we let the drivers calculate it for themselves?  I go for the latter, as
> > fbcon really should not have any business with hardware.
> 
> What about the following solution: What if fbcon_resize sets the clock 
> in the var to 0? We could use this to force low level drivers to decide 
> on the clock for themselves. Otherwise, ie if the clock field is 
> non-zero, they are supposed to take it as the desired clock.
> 

Yes, that's another solution.  Just invalidate the timings and force the
driver to compute a modeline each time.

Tony

Re: [Linux-fbdev-devel] Some questions

[Geert U. <ge...@li...>]

On Thu, 6 Mar 2003, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> > fbcon_resize() is not that broken, it's only trying to do what it's
> > supposed to do.  It is indeed limited because it is trying to outguess
> > the low-level drivers on the best resolution for a window size.
> > 
> > However, the brokenness is really on the driver side.  They are unable
> > to change the video mode unless they are supplied with the correct
> > timing parameters where in fact they actually have the best knowledge on
> > how to calculate them.  
> 
> Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
> requires at least x and y dimension AND A CLOCK (or a vertical refresh 
> rate, which I would prefer).
> 
> The driver is supposed to handle the "var"s it's fed. If that var is 
> like the ones that result from the current fbcon_resize, namely with a 
> new x and y res, but no valid clock, how on earth should the driver do 
> this then? It receives a var which looks correct, and in fact, *could* 
> be correct sometimes:
> 
> Suppose we have another application, say DirectFB, feeding the low level 
> drivers with complete and correct "var"s.
> 
> In both cases we have valid x any y resultions, and a non-zero clock field.
> 
> Should we then let the driver read the x and y resolution and forget 
> about the rest of that var? I hardly think that's what the public var is 
> for. It could be reduced to a struct { USHORT xres, USHORT yres } then.
> 
> > So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
> > we let the drivers calculate it for themselves?  I go for the latter, as
> > fbcon really should not have any business with hardware.
> 
> What about the following solution: What if fbcon_resize sets the clock 
> in the var to 0? We could use this to force low level drivers to decide 
> on the clock for themselves. Otherwise, ie if the clock field is 
> non-zero, they are supposed to take it as the desired clock.

What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
current resolution?

If you use stty to change the number of cols/rows, or change the font, or use
fbset, your text console may end up being smaller or larger than the real
screen size, in which case margins are cleared, or columns/lines are lost.
(Optionally, we can center the text console if it's smaller than the real
 screen size.)

IMHO this is the most orthogonal approach. Fbcon takes care of the text
console, fbdev takes care of the graphics hardware and the video mode. Both
parts do (try to) not influence each other.

Optionally, fbset can call stty to change the number of cols/rows, if the user
wants that.

What do you think?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

James Simmons wrote:
> Actually it is normal. Changing a console via stty has been around 
> forever. When you ask what size is your VGA console you say 80x25. Now why 
> is that. The main thing is people think of it as a text mode and second
> you really can't change it or boot to to many different size resolutions.
> Does this mean VGA console should be limited? NO!!! I plan to make vgacon 
> some day changable in window size. So the final answer is:
> 
> Portablity. 
> 
> You could use stty or some other program using the tty layer to change the 
> resolution on any type of hardware running any type of console driver. The 
> next best thing is some day we can get ride of con_switch in the upper 
> console layers. We can just use set_font and vc_resize on VT switching 
> since that is all you are doing on vc_switching. 

OK, if this is your final word on this, I - as the maintainer of a 
driver which due to LCD and TV handling only supports a (huge) number of 
built-in modes - am forced to do the following:

If I receive a request for a mode that isn't supported, I go with the 
next larger one that is supported. Even if that leads to differences 
from requested 813x601 to displayed 1024x768.

Hope you and your console code can deal with that then :)

>>BTW: What happens currently if I instruct console to replace the current 
>>font with a bigger one (if that's possible at run-time at all) ?
> 
> 
> It should work.

... and lead to a mode switch? Funny: If I switch from a 8x16 font to a 
bigger one, because I forgot my glasses, the mode is switched to a 
higher one, because the number of cols and rows hasn't changed, leaving 
me with a nearly identical charcter size?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...            http://www.winischhofer.net/

Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 16:33, Geert Uytterhoeven wrote:
> On Wed, 5 Mar 2003, James Simmons wrote:
> > > > We should split the monitor programing stuff out from stuff like bpp etc.
> > > > Now if you think about it we can do things like change the bpp without 
> > > > having to redo the monitor programming. This is the flaw with the old and 
> > > > even the new api. 
> > > 
> > > You could have done that from the beginning. Just look at which fields have
> > > changed and which haven't.
> > 
> > I should of but didn't because I knew driver would take teh path of lest 
> > resistance to port there drivers. TO much change would have made the 
> > current situtation much much worst. 
> 
> One other reason why this isn't done is because X may interfere with it. If we
> don't do a full register update, but change the parts that need a change only,
> we will see less flickering (no PLL reprogramming), but we will suffer if X
> doesn't restore the registers to the exact same values they were before.
> 

Ideally, that is what should happen.  However, fb_set_var does a check
if the passed var is different from the default var.  If it's the same,
fb_set_par is skipped.  Switching back from X, this check will be mostly
false, so fb_set_par will be skipped, and register refreshing would have
failed.

So, I think fbcon should also detect if the previous console is not
fbcon (ie previous con > last_fbvc || previous con < first_fbvc), and if
it isn't, force an fb_set_par.

Tony

Re: [Linux-fbdev-devel] Some questions

[Sven L. <lu...@dp...>]

On Thu, Mar 06, 2003 at 09:33:34AM +0100, Geert Uytterhoeven wrote:
> On Wed, 5 Mar 2003, James Simmons wrote:
> > > > We should split the monitor programing stuff out from stuff like bpp etc.
> > > > Now if you think about it we can do things like change the bpp without 
> > > > having to redo the monitor programming. This is the flaw with the old and 
> > > > even the new api. 
> > > 
> > > You could have done that from the beginning. Just look at which fields have
> > > changed and which haven't.
> > 
> > I should of but didn't because I knew driver would take teh path of lest 
> > resistance to port there drivers. TO much change would have made the 
> > current situtation much much worst. 
> 
> One other reason why this isn't done is because X may interfere with it. If we
> don't do a full register update, but change the parts that need a change only,
> we will see less flickering (no PLL reprogramming), but we will suffer if X
> doesn't restore the registers to the exact same values they were before.

X is supposed to do that, even if it doesn't know anything about fbdevs,
maybe especially if it doesn't know anything about fbdevs. If it knows
about fbdev and uses it, X should not be touching the modes anyway,
right ?

So, we are saving/restoring things twice, one time in X, the other in
the fbdev.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

Antonino Daplas wrote:
> fbcon_resize() is not that broken, it's only trying to do what it's
> supposed to do.  It is indeed limited because it is trying to outguess
> the low-level drivers on the best resolution for a window size.
> 
> However, the brokenness is really on the driver side.  They are unable
> to change the video mode unless they are supplied with the correct
> timing parameters where in fact they actually have the best knowledge on
> how to calculate them.  

Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
requires at least x and y dimension AND A CLOCK (or a vertical refresh 
rate, which I would prefer).

The driver is supposed to handle the "var"s it's fed. If that var is 
like the ones that result from the current fbcon_resize, namely with a 
new x and y res, but no valid clock, how on earth should the driver do 
this then? It receives a var which looks correct, and in fact, *could* 
be correct sometimes:

Suppose we have another application, say DirectFB, feeding the low level 
drivers with complete and correct "var"s.

In both cases we have valid x any y resultions, and a non-zero clock field.

Should we then let the driver read the x and y resolution and forget 
about the rest of that var? I hardly think that's what the public var is 
for. It could be reduced to a struct { USHORT xres, USHORT yres } then.

> So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
> we let the drivers calculate it for themselves?  I go for the latter, as
> fbcon really should not have any business with hardware.

What about the following solution: What if fbcon_resize sets the clock 
in the var to 0? We could use this to force low level drivers to decide 
on the clock for themselves. Otherwise, ie if the clock field is 
non-zero, they are supposed to take it as the desired clock.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...            http://www.winischhofer.net/

Re: [Linux-fbdev-devel] Some questions

[Geert U. <ge...@li...>]

On Wed, 5 Mar 2003, James Simmons wrote:
> > > We should split the monitor programing stuff out from stuff like bpp etc.
> > > Now if you think about it we can do things like change the bpp without 
> > > having to redo the monitor programming. This is the flaw with the old and 
> > > even the new api. 
> > 
> > You could have done that from the beginning. Just look at which fields have
> > changed and which haven't.
> 
> I should of but didn't because I knew driver would take teh path of lest 
> resistance to port there drivers. TO much change would have made the 
> current situtation much much worst. 

One other reason why this isn't done is because X may interfere with it. If we
don't do a full register update, but change the parts that need a change only,
we will see less flickering (no PLL reprogramming), but we will suffer if X
doesn't restore the registers to the exact same values they were before.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] Re: FBdev updates.

[Sven L. <lu...@dp...>]

On Thu, Mar 06, 2003 at 04:05:32PM +0800, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 15:35, Sven Luther wrote:
> > >  
> > > >   And one (or two...) generic questions: why is not pseudo_palette
> > > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> > > 
> > > pseudo_palette was originally designed to be a pointer to some kind of 
> > > data for color register programming. For example many PPC graphics cards 
> > > have a color register region. Now you could have that point to 
> > 
> > Does this correspond to the LUT i have in my boards ?
> > 
> > BTW, what is the point in having a pseudo_palette if you can store
> > the colors in the onchip LUT table.
> > 
> 
> The hardware clut typically stores each color channel separately.  In
> software terms, this is akin to struct fb_cmap.  The pseudo_palette, on
> the other hand, is a pixel LUT, the contents of which can be directly
> written to the framebuffer without it ever knowing the format at all, ie
> it does not matter if it's RGB or YUV.  This makes the upper layer
> independent of the low-lever driver (at least in terms of colorspace
> formats).

Ok, thanks, ...

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Re: FBdev updates.

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 15:35, Sven Luther wrote:
> >  
> > >   And one (or two...) generic questions: why is not pseudo_palette
> > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> > 
> > pseudo_palette was originally designed to be a pointer to some kind of 
> > data for color register programming. For example many PPC graphics cards 
> > have a color register region. Now you could have that point to 
> 
> Does this correspond to the LUT i have in my boards ?
> 
> BTW, what is the point in having a pseudo_palette if you can store
> the colors in the onchip LUT table.
> 

The hardware clut typically stores each color channel separately.  In
software terms, this is akin to struct fb_cmap.  The pseudo_palette, on
the other hand, is a pixel LUT, the contents of which can be directly
written to the framebuffer without it ever knowing the format at all, ie
it does not matter if it's RGB or YUV.  This makes the upper layer
independent of the low-lever driver (at least in terms of colorspace
formats).

Tony

Re: [Linux-fbdev-devel] Feature Freeze?

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 15:03, Carlo E. Prelz wrote:
> I see there currently is much activity on the list. I would like to
> present the point of view of a heavy framebuffer user: I write
> multimedia code for artists, and I generally generate video via the
> framebuffer layer, and trusted old matrox cards (from the Millennium
> II to the G550). The general process is:
> 
> - open the framebuffer unit
> - FBIOGET_VSCREENINFO
> - change the appropriate values in fb_var_screeninfo
> - FBIOPUT_VSCREENINFO
> - mmap
> - happily write pixels to the memory area

All of the above should still work with the 2.5.  Care was taken to
prevent user application breakage. 

> 
> This, multiplied for all the video heads that I use within the same
> program (up to 5 per PC, up to now, *including* the console screen -
> in this case I control the machine from a network connection).
> 
> I am especially in need to change the BPP value (often using 16BPP
> mode), and in a couple of occasions (the latest 2 weeks ago) I had to
> feed the output of old G200's to large monitors who are only capable
> of TV resolution. This means setting the framebuffer to 768x576 (PAL)
> and *interlaced*. The framebuffer model that still survives in 2.4
> allows me to obtain all this. 

You can still do it for the 2.5, except that the matroxfb is not ported
yet.

> 
> I am not much familiar with all the terminology that is used for the
> new layer. Actually, this framebuffer revolution is what keeps me from
> enjoying (!) the kernel bleeding edge, as I used to do since almost 10
> years ago. 
> 
> Can I poll the list's huge knowledge to find out if and how I can
> obtain the same result with the new layer?
> 

You still can, in general, use the framebuffer as you would use it in
the 2.2.- 2.4 versions.  The main difference is console window
resizing.  As you probably know, in 2.4, resizing was done through the
fbdev layer and then the information is transmitted to the console.  In
2.5, it is currently the opposite way, from the console to fbdev.  The
only application that I know of that is able to do that is stty, which
in its current incarnation has very limited capability.  However, you
can still use fbset to change other parameters (color depth,
acceleration, etc), anything that will not affect the window size.

So the debate really is, should fbset support for console resizing be
reimplemented? Or should console resizing through stty be made more
powerful, at least to create a video mode that is usable, and then just
use fbset later on to fine tune the new video mode? The former is easy,
the latter is saner but more difficult to code.

The matroxfb on the other hand, is the most complicated fb driver
around, so it is perfectly understandable that rewriting the driver for
the 2.5 will take some time.  Temporarily, you can use Petr's patches
until it is ported over to 2.5.  

ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz


The new layer may not produce something tangible in terms of user
experience (except perhaps for a faster console), but it should pave the
way for better things in the future.

Tony

Re: [Linux-fbdev-devel] Re: FBdev updates.

[Sven L. <lu...@dp...>]

On Wed, Mar 05, 2003 at 08:22:26PM +0000, James Simmons wrote:
> 
> > Hi,
> >   while waiting on these updates I updated matroxfb a bit
> > (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz),
> > so that it now uses fb_* for cfb modes, and putcs/... hooks for
> > text mode. I have still dozen of changes in fbcon.c which I have
> > to eliminate (mainly logo painting and cursor handling - for now
> > I still use revc method, mainly because of I did not make into it yet).
> 
> I grabbed your latest patch and started to merge it with my latest work on 
> the matrox driver. As soon as I'm done merging my matrox changes I will 
> send you a patch right away.
> 
> >   My main concern now is 12x22 font... Accelerator setup
> > is so costly for each separate painted character that for 8bpp 
> > accelerated version is even slower than unaccelerated one :-(
> > (and almost twice as slow when compared with 2.4.x).
> 
> Try the latest patch I released.
>  
> >   And one (or two...) generic questions: why is not pseudo_palette
> > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> 
> pseudo_palette was originally designed to be a pointer to some kind of 
> data for color register programming. For example many PPC graphics cards 
> have a color register region. Now you could have that point to 

Does this correspond to the LUT i have in my boards ?

BTW, what is the point in having a pseudo_palette if you can store
the colors in the onchip LUT table.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Feature Freeze?

[Carlo E. P. <fl...@fl...>]

	Subject: Re: [Linux-fbdev-devel] Feature Freeze?
	Date: gio, mar 06, 2003 at 09:18:07 +0800

Quoting Antonino Daplas (ad...@po...):

> > > > 2. console resizing using fbset (besides stty)?
> > > 
> > > Nice, if it's not too much work.
> > 
> > :-( I hope to improve fbcon to handle this.
> >  
> 
> If you're really against using fbset to resize the console, then the
> first step is to protect the console from the "dangers" of fbset. 
> Secondly, we can have fbcon_resize() validate the mode instead of just
> blindly calling fb_set_var().  If it's not valid, then it can also fetch
> a working mode for it.  The user can then fine tune the timings using
> fbset afterwards.
> 
> 
> So, do we allow fbcon to handle mode validating and fetching, or do we
> just leave all this to fbdev? At least let's bring out some ideas on how
> to go about doing this.  Having a working idea, even if dumb, should
> interest other developers in contributing. 

I see there currently is much activity on the list. I would like to
present the point of view of a heavy framebuffer user: I write
multimedia code for artists, and I generally generate video via the
framebuffer layer, and trusted old matrox cards (from the Millennium
II to the G550). The general process is:

- open the framebuffer unit
- FBIOGET_VSCREENINFO
- change the appropriate values in fb_var_screeninfo
- FBIOPUT_VSCREENINFO
- mmap
- happily write pixels to the memory area

This, multiplied for all the video heads that I use within the same
program (up to 5 per PC, up to now, *including* the console screen -
in this case I control the machine from a network connection).

I am especially in need to change the BPP value (often using 16BPP
mode), and in a couple of occasions (the latest 2 weeks ago) I had to
feed the output of old G200's to large monitors who are only capable
of TV resolution. This means setting the framebuffer to 768x576 (PAL)
and *interlaced*. The framebuffer model that still survives in 2.4
allows me to obtain all this. 

I am not much familiar with all the terminology that is used for the
new layer. Actually, this framebuffer revolution is what keeps me from
enjoying (!) the kernel bleeding edge, as I used to do since almost 10
years ago. 

Can I poll the list's huge knowledge to find out if and how I can
obtain the same result with the new layer?

Thanks a lot in advance...

Carlo 

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fl...@fl...             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

Re: [Linux-fbdev-devel] [BK updates] More updates.

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 02:13, James Simmons wrote:
> 
> Hi folks. 
> 
>     I just pieced together various patches. I think we need to push this 
> code to linus. It has gotten pretty big.. Can people test  it please 
> before I sen it.
> 
> Diff:  http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

James,

Something's wrong with the patch, it removed fb.h, the Makefiles and
possibly a bunch of other files.

Tony

Re: [Linux-fbdev-devel] Re: FBdev updates.

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 04:23, James Simmons wrote:
> 
> > >   And one (or two...) generic questions: why is not pseudo_palette
> > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> > 
> > Yes, all drivers should treat the pseudo_palette as u32* anyway, so why
> > not change pseudo-palette from void* to u32*?
> 
> See other email.
> 
> > > And why we do not fill this pseudo_palette with
> > > i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
> > > pseudocolor? This allowed me to remove couple of switches and tests
> > > from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
> > > but I did not changed these two in my benchmarks below).
> > 
> > I also agree for a different reason.  Cards with unconventional formats
> > (such as monochrome at 8 bpp - 0 for black , 0xff for white) will not
> > work with the current code.
> 
> Isn't that the job of setcolreg?
> 
setcolreg does that for directcolor and truecolor modes, because they're
the only ones that uses the pseudo_palette.  See all driver codes, the
pseudo_palette is never initialized if in pseudo_color.

The purpose of the pseudo_palette is to enable to write pixels to the
framebuffer without knowing the color format at all.  So, if you have
monochrome, then black is 0 and white is 1.  But for monochrome 8bpp,
black is 0 and white is 0xff. 

fbcon will send 0's and 1's, thus 0 and 1 will be written to the
framebuffer.  If the drawing functions referred to the pseudo_palette,
whatever the visual format, then 0 and 0xff will be written, as it
should be.

Tony
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 06:21, Thomas Winischhofer wrote:
> James Simmons wrote:
> > I disagree that fbset is the solution to all things. The problem is 
> > fbcon_resize is severally broken. The reality is that there are fixed mode 
> > resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
> > shoudl do is set the console mode fit slightly smaller than that the 
> > actually resolution. The reason being is partially drawn fonts at the 
> > bottom of the screen would look bad. So clearing the margins also has to 
> > be fixed. This way we clean up the screen for situtations where the 
> > console screen size doesn't quite fit the resolution. This is what shoudl 
> > be done. 
> 
> Excuse me that I dare to comment on this as a total fbdev-rookie:
> 
> Please think about usability, too. Forcing people to fiddle with rows 
> and cols, requiring knowledge about font sizes and stuff is at least 
> inappropriate. Folks are used to think in resolutions, that's what they 
> understand, and that's what is most obvious. I can't imagine anyone 
> caring about the amount of rows or columns on a text screen.
> 

If you are working in a console, then you indeed need to work on rows
and columns.

> BTW: What happens currently if I instruct console to replace the current 
> font with a bigger one (if that's possible at run-time at all) ?

It will work, as the rows and columns are recalculated.

Tony