Sane behavior of fbset

Sane behavior of fbset

[Antonino A. Daplas]

Hi,

Currently, using fbset either corrupts the display, or at worst, hangs the GPU.  I consider
this a critical bug.  I don't want to discuss the pros/cons of using fbset vs stty to
change the console size, but we need to make sure that using fbset (or any utility
that utilizes the fb_set_var ioctl) does not produce undefined behavior.  There are 
at least 3 possibilities:

1.  Revert to 2.4 behavior.  This is easy to add since fbdev already has a notifier 
support. (I already have working code for this). Of course, stty will still work.

2.  Make the set_var ioctl return immediately if the vc_mode of the current display is 
KD_TEXT. Basically, fbset becomes an informational utility only. I don't know the 
repercussions of this with userland fb applications though.

3.  Modify fbset (and other similar utilities, if there are any) so it also issues an 
'stty-like' call after a 'set_var' call.   

Note: As mentioned by many people before, it's almost impossible to completely 
preserve per-console mode info because of the lack of a per-display var.  So even 
if we agree to implement #1,  it cannot completely match 2.4 behavior. Also, the lack
of per-display var means that drivers must be able to handle mode changes without 
any help.  James' fb_find_mode support in fbcon_resize does partly alleviate this 
limitation.

Comments?

Tony




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Sane behavior of fbset

[Geert Uytterhoeven]

On Fri, 18 Jun 2004, Antonino A. Daplas wrote:
> Currently, using fbset either corrupts the display, or at worst, hangs the GPU.  I consider
> this a critical bug.  I don't want to discuss the pros/cons of using fbset vs stty to
> change the console size, but we need to make sure that using fbset (or any utility
> that utilizes the fb_set_var ioctl) does not produce undefined behavior.  There are
> at least 3 possibilities:
>
> 1.  Revert to 2.4 behavior.  This is easy to add since fbdev already has a notifier
> support. (I already have working code for this). Of course, stty will still work.
>
> 2.  Make the set_var ioctl return immediately if the vc_mode of the current display is
> KD_TEXT. Basically, fbset becomes an informational utility only. I don't know the
> repercussions of this with userland fb applications though.
>
> 3.  Modify fbset (and other similar utilities, if there are any) so it also issues an
> 'stty-like' call after a 'set_var' call.
>
> Note: As mentioned by many people before, it's almost impossible to completely
> preserve per-console mode info because of the lack of a per-display var.  So even
> if we agree to implement #1,  it cannot completely match 2.4 behavior. Also, the lack
> of per-display var means that drivers must be able to handle mode changes without
> any help.  James' fb_find_mode support in fbcon_resize does partly alleviate this
> limitation.
>
> Comments?

I vote for 1, and re-adding per-display vars.

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 The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Sane behavior of fbset

[John Zielinski]

Antonino A. Daplas wrote:

>1.  Revert to 2.4 behavior.  This is easy to add since fbdev already has a notifier 
>support. (I already have working code for this). Of course, stty will still work.
>
>  
>
Definitely #1.   The functionality is very easy to add to the kernel as 
most of it is already in place.

>2.  Make the set_var ioctl return immediately if the vc_mode of the current display is 
>KD_TEXT. Basically, fbset becomes an informational utility only. I don't know the 
>repercussions of this with userland fb applications though.
>
>  
>
Several people have already started doing work adding fb mode changing 
to sysfs.  Fbset will most likely become a wrapper around the sysfs 
interface.

>3.  Modify fbset (and other similar utilities, if there are any) so it also issues an 
>'stty-like' call after a 'set_var' call.   
>
>  
>
Ug, please no.  That's just asking for trouble.  Now the app would have 
to figure out what the font size is so that adds a third call.  If the 
app gets the calculation between x-y -> row-col wrong then the screen 
would be messed up at best or we'd get an infinite loop at worse (like 
one of the earlier patches to the kernel did).

>Note: As mentioned by many people before, it's almost impossible to completely 
>preserve per-console mode info because of the lack of a per-display var.  So even 
>if we agree to implement #1,  it cannot completely match 2.4 behavior. Also, the lack
>of per-display var means that drivers must be able to handle mode changes without 
>any help.  James' fb_find_mode support in fbcon_resize does partly alleviate this 
>limitation.
>  
>
Several people on the list are pushing to have per-console var put back 
in.   This is a far as it should go for the 2.6.x series.  There are 
more elaborate solutions proposed for the 2.7 kernel.

John




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Sane behavior of fbset

[David Eger]

On Fri, Jun 18, 2004 at 09:45:12AM +0800, Antonino A. Daplas wrote:
> Hi,
> 
> Currently, using fbset either corrupts the display, or at worst, hangs the GPU.  I consider
> this a critical bug.  I don't want to discuss the pros/cons of using fbset vs stty to
> change the console size, but we need to make sure that using fbset (or any utility
> that utilizes the fb_set_var ioctl) does not produce undefined behavior.  There are 
> at least 3 possibilities:
> 
> 1.  Revert to 2.4 behavior.  This is easy to add since fbdev already has a notifier 
> support. (I already have working code for this). Of course, stty will still work.

Just for my enlightenment, could you give a synopsis of 2.4 behavior
versus 2.6 behavior?

-dte


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Sane behavior of fbset

[Antonino A. Daplas]

On Saturday 19 June 2004 01:38, David Eger wrote:
> On Fri, Jun 18, 2004 at 09:45:12AM +0800, Antonino A. Daplas wrote:
> > Hi,
> >
> > Currently, using fbset either corrupts the display, or at worst, hangs
> > the GPU.  I consider this a critical bug.  I don't want to discuss the
> > pros/cons of using fbset vs stty to change the console size, but we need
> > to make sure that using fbset (or any utility that utilizes the
> > fb_set_var ioctl) does not produce undefined behavior.  There are at
> > least 3 possibilities:
> >
> > 1.  Revert to 2.4 behavior.  This is easy to add since fbdev already has
> > a notifier support. (I already have working code for this). Of course,
> > stty will still work.
>
> Just for my enlightenment, could you give a synopsis of 2.4 behavior
> versus 2.6 behavior?
>

In 2.4

1. you can use fbset to change the console window size.

2. stty will not change the window size (produce a small viewport or the 
contents will be clipped)

3. Switching from one console to another will preserve the video mode.  
Example:
tty1 - 800x600-16@85
tty2 - 1024x768-8@60

When switching from tty2 to tty1 or vice versa, your mode setting will be 
retained.  This is because each console has its own copy of  
fb_var_screeninfo.

4. The need to create/validate a modeline is optional as this is expected to 
be done in userland.
 
In 2.6

1. If you use fbset, you will get screen corruption or hang the GPU

2. stty will do the function of fbset.  However, stty will only pass rows and 
cols (xres and yres respectively).  There is no information for bit depth, 
timings, virtual resolution, etc.

3. Switching from one console to another may or may not preserve your mode 
settings.  In the example above, If I switch from tty2 to tty1, I might get a 
display with a refresh of 60Hz at 8 bpp.  The mode you get will depend on the 
drivers capability to pick/create a modeline.  This is because you only have 
1 valid fb_var_screeninfo at one time, and this is info->var.

4. Creation/validation of modelines by drivers is practically a necessity. 

Of course, 2.6 does have some good points.  It's easier to write a driver for 
it, the resulting driver code is probably smaller, it's faster, and fbcon and 
fbdev are separated, ie you can load fbdev without taking over your console.  
The last one is probably useful for embedded devices.

Tony




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Sane behavior of fbset

[David Eger]

On Sat, Jun 19, 2004 at 02:40:46AM +0800, Antonino A. Daplas wrote:
> 
> In 2.6
> 
> 1. If you use fbset, you will get screen corruption or hang the GPU
> 
> 2. stty will do the function of fbset.  However, stty will only pass rows and 
> cols (xres and yres respectively).  There is no information for bit depth, 
> timings, virtual resolution, etc.
> 

So *this* is what's going on with my port of the cirrusfb driver--why fbset 
wasn't working... for radeonfb fbset still works in 2.6, so i didn't realize 
there was this problem... What's so wonky with the fbset code path that 
screws things up? and why does stty work?

heck, in this case, I'm of the mind to just send the cirrusfb update 
upstream...  James?  you ever test the patch on your hardware?

-dte


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Sane behavior of fbset

[Antonino A. Daplas]

On Saturday 19 June 2004 11:16, David Eger wrote:
> On Sat, Jun 19, 2004 at 02:40:46AM +0800, Antonino A. Daplas wrote:
> > In 2.6
> >
> > 1. If you use fbset, you will get screen corruption or hang the GPU
> >
> > 2. stty will do the function of fbset.  However, stty will only pass rows
> > and cols (xres and yres respectively).  There is no information for bit
> > depth, timings, virtual resolution, etc.
>
> So *this* is what's going on with my port of the cirrusfb driver--why fbset
> wasn't working... for radeonfb fbset still works in 2.6, so i didn't
> realize there was this problem... What's so wonky with the fbset code path
> that screws things up? and why does stty work?

The flow of fbset is upstream:  fbset->fbdev->fbcon->vc (2.4 code)
The flow of stty is downstream: stty->vc->fbcon->fbdev (2.6 code)

I don't know how radeonfb does it though.

Tony




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Sane behavior of fbset

[John Zielinski]

David Eger wrote:

>So *this* is what's going on with my port of the cirrusfb driver--why fbset 
>wasn't working... for radeonfb fbset still works in 2.6, so i didn't realize 
>there was this problem... What's so wonky with the fbset code path that 
>screws things up? and why does stty work?
>  
>
The radeonfb fbset doesn't work right out of the box.  The fbset path 
doesn't resize the vc rows and columns.  I use a patch to get things to 
work.  You have to be careful as there is potential for an infinite loop 
if the calculation between xres-yres and cols-rows is off.  I can't post 
the patch just yet as things have changed in fbcon.c in 2.6.7 so I need 
to update and test it.

John




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Sane behavior of fbset

[John Zielinski]

Antonino A. Daplas wrote:

>The flow of fbset is upstream:  fbset->fbdev->fbcon->vc (2.4 code)
>The flow of stty is downstream: stty->vc->fbcon->fbdev (2.6 code)
>  
>
The flow of fbset in 2.6: fbset->fbdev->fbcon
The flow of fbset after my patch: fbset->fbdev->fbcon->vc
The flow of fbset if calc error: 
fbset->fbdev->fbcon->vc->fbcon->fbdev->fbcon->vc-> etc.

As long as  graphics_res / font_size = text_res then fbcon will not try 
to resize the vc.  If there are any errors introduced into the 
calculations then you end up with an infinite loop.

John






-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Sane behavior of fbset

[Benjamin Herrenschmidt]

> The flow of fbset is upstream:  fbset->fbdev->fbcon->vc (2.4 code)
> The flow of stty is downstream: stty->vc->fbcon->fbdev (2.6 code)
> 
> I don't know how radeonfb does it though.

I still think (didn't I repeat it often enough) that the whole idea
of stty "inventing" modes based on console size is broken. We simply
can't rely on good enough monitor detection & mode list building to
be able to pick proper modes. Not only our code is far from ready for
that, but it will also call all sort of problems to users (remember
you monitors that need different subtle geometry settings for each
different mode you use ?)

It may have looked like a nice idea, but I think it's just wrong.

fbset sends an ioctl straight to the fbdev, and doesn't update fbcon
at the moment. The callback mecanism I added for power management
should allow to restore 2.4 functionality there, but this has not
been implemented yet afaik.

Ben.




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[Geert Uytterhoeven]

On Wed, 23 Jun 2004, Benjamin Herrenschmidt wrote:
> > The flow of fbset is upstream:  fbset->fbdev->fbcon->vc (2.4 code)
> > The flow of stty is downstream: stty->vc->fbcon->fbdev (2.6 code)
> >
> > I don't know how radeonfb does it though.
>
> I still think (didn't I repeat it often enough) that the whole idea
> of stty "inventing" modes based on console size is broken. We simply
> can't rely on good enough monitor detection & mode list building to
> be able to pick proper modes. Not only our code is far from ready for
> that, but it will also call all sort of problems to users (remember
> you monitors that need different subtle geometry settings for each
> different mode you use ?)
>
> It may have looked like a nice idea, but I think it's just wrong.
>
> fbset sends an ioctl straight to the fbdev, and doesn't update fbcon
> at the moment. The callback mecanism I added for power management
> should allow to restore 2.4 functionality there, but this has not
> been implemented yet afaik.

Oh yes, patches for that are starting to flow around!

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 sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[John Zielinski]

Benjamin Herrenschmidt wrote:

>It may have looked like a nice idea, but I think it's just wrong.
>  
>
I think that the implementation is wrong, not the whole idea.  Currently 
the vt_resize ioctl changes the vt size then tries to set the resolution 
leading to a whole bunch of problems when a suitable resolution can't be 
found and makes the fbset result ion change code path ugly as well.

What should happen is that the vt_resize ioctl should be sent to the 
console driver first and then the console driver calls back the vt layer 
with the modified  row and column numbers based on the closest 
resolution found.

So what we have right now is:

vt_ioctl (VT_RESIZE) -> vc_resize -> resize_screen -> con_resize ->  
fb_set_var -> fbcon_event_notify -> vc_resize*

* or equivilent code depending on who's patch you use

Which should be:

vt_ioctl (VT_RESIZE) -> resize_screen -> con_resize -> fb_set_var & 
vc_resize

You'd have to have a per vt var in order to have different console sizes 
on different vt's this way.  The reason for not using the 
fbcon_event_notify is that it won't be called when the vt is not in the 
forground and I don't belive that a we need to resize the console when 
switching between different vt's.  A vc_resize would the be necessary in 
the fb_ioctl FBIOPUT_VSCREENINFO code path in this case.

John




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[jsimmons]

> > 1.  Revert to 2.4 behavior.  This is easy to add since fbdev already has a notifier
> > support. (I already have working code for this). Of course, stty will still work.
> >
> > 2.  Make the set_var ioctl return immediately if the vc_mode of the current display is
> > KD_TEXT. Basically, fbset becomes an informational utility only. I don't know the
> > repercussions of this with userland fb applications though.
> >
> > 3.  Modify fbset (and other similar utilities, if there are any) so it also issues an
> > 'stty-like' call after a 'set_var' call.
> >
> > Note: As mentioned by many people before, it's almost impossible to completely
> > preserve per-console mode info because of the lack of a per-display var.  So even
> > if we agree to implement #1,  it cannot completely match 2.4 behavior. Also, the lack
> > of per-display var means that drivers must be able to handle mode changes without
> > any help.  James' fb_find_mode support in fbcon_resize does partly alleviate this
> > limitation.
> >
> > Comments?
> 
> I vote for 1, and re-adding per-display vars.

I have no problem adding in a notifier for fbset. I don't agree with 
adding in per VC vars. The reason is that every VC, all 64, will have a 
copy of struct fb_var_screeninfo. That is really heavy for embedded 
devices. Instead with a modedb we have one copy of different kinds of 
modes. What we need to do is add valid modes that are not present in 
modedb. 


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[jsimmons]

> wasn't working... for radeonfb fbset still works in 2.6, so i didn't realize 
> there was this problem... What's so wonky with the fbset code path that 
> screws things up? and why does stty work?

radeonfb work? Interesting.
 
> heck, in this case, I'm of the mind to just send the cirrusfb update 
> upstream...  James?  you ever test the patch on your hardware?

I didn't get a chance last night. I test Riva instead.



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[jsimmons]

> >The flow of fbset is upstream:  fbset->fbdev->fbcon->vc (2.4 code)
> >The flow of stty is downstream: stty->vc->fbcon->fbdev (2.6 code)
> >  
> >
> The flow of fbset in 2.6: fbset->fbdev->fbcon
> The flow of fbset after my patch: fbset->fbdev->fbcon->vc
> The flow of fbset if calc error: 
> fbset->fbdev->fbcon->vc->fbcon->fbdev->fbcon->vc-> etc.
> 
> As long as  graphics_res / font_size = text_res then fbcon will not try 
> to resize the vc.  If there are any errors introduced into the 
> calculations then you end up with an infinite loop.

That shouldn't be the case. fbcon picks a rounded up mode from the text 
resolution. It is a best fit match.



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[Geert Uytterhoeven]

On Wed, 23 Jun 2004 jsimmons@pentafluge.infradead.org wrote:
> > > 1.  Revert to 2.4 behavior.  This is easy to add since fbdev already has a notifier
> > > support. (I already have working code for this). Of course, stty will still work.

> > > Note: As mentioned by many people before, it's almost impossible to completely
> > > preserve per-console mode info because of the lack of a per-display var.  So even
> > > if we agree to implement #1,  it cannot completely match 2.4 behavior. Also, the lack
> > > of per-display var means that drivers must be able to handle mode changes without
> > > any help.  James' fb_find_mode support in fbcon_resize does partly alleviate this
> > > limitation.
> >
> > I vote for 1, and re-adding per-display vars.
>
> I have no problem adding in a notifier for fbset. I don't agree with
> adding in per VC vars. The reason is that every VC, all 64, will have a
> copy of struct fb_var_screeninfo. That is really heavy for embedded
> devices. Instead with a modedb we have one copy of different kinds of
> modes. What we need to do is add valid modes that are not present in
> modedb.

If size matters, embedded devices can always disable virtual consoles
completely, so only one var is needed.

Furthermore, what about making the maximum number of virtual consoles
configurable, and/or handling them dynamically (most systems have only a few of
them in active use)?

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 sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[jsimmons]

> I still think (didn't I repeat it often enough) that the whole idea
> of stty "inventing" modes based on console size is broken. We simply
> can't rely on good enough monitor detection & mode list building to
> be able to pick proper modes. Not only our code is far from ready for
> that, but it will also call all sort of problems to users (remember
> you monitors that need different subtle geometry settings for each
> different mode you use ?)
> 
> It may have looked like a nice idea, but I think it's just wrong.

Its a POSIX standard. You need to yell at them. 

> fbset sends an ioctl straight to the fbdev, and doesn't update fbcon
> at the moment. The callback mecanism I added for power management
> should allow to restore 2.4 functionality there, but this has not
> been implemented yet afaik.

It will be added back. I didn't merge the one from before because it had 
problems. 


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[jsimmons]

> > I have no problem adding in a notifier for fbset. I don't agree with
> > adding in per VC vars. The reason is that every VC, all 64, will have a
> > copy of struct fb_var_screeninfo. That is really heavy for embedded
> > devices. Instead with a modedb we have one copy of different kinds of
> > modes. What we need to do is add valid modes that are not present in
> > modedb.
> 
> If size matters, embedded devices can always disable virtual consoles
> completely, so only one var is needed.
> 
> Furthermore, what about making the maximum number of virtual consoles
> configurable, and/or handling them dynamically (most systems have only a few of
> them in active use)?

That is a 2.7.X issue. Even still having 2 VCs meanings having two 
identical vars. That is heavy. Having that mode stored in modedb is one 
copy for both VCs.



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[Geert Uytterhoeven]

On Wed, 23 Jun 2004 jsimmons@pentafluge.infradead.org wrote:
> > > I have no problem adding in a notifier for fbset. I don't agree with
> > > adding in per VC vars. The reason is that every VC, all 64, will have a
> > > copy of struct fb_var_screeninfo. That is really heavy for embedded
> > > devices. Instead with a modedb we have one copy of different kinds of
> > > modes. What we need to do is add valid modes that are not present in
> > > modedb.
> >
> > If size matters, embedded devices can always disable virtual consoles
> > completely, so only one var is needed.
> >
> > Furthermore, what about making the maximum number of virtual consoles
> > configurable, and/or handling them dynamically (most systems have only a few of
> > them in active use)?
>
> That is a 2.7.X issue. Even still having 2 VCs meanings having two
> identical vars. That is heavy. Having that mode stored in modedb is one
> copy for both VCs.

And how much space does modedb (which used to be __initdata) need?

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 sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[jsimmons]

> > identical vars. That is heavy. Having that mode stored in modedb is one
> > copy for both VCs.
> 
> And how much space does modedb (which used to be __initdata) need?

I couldn't agree with you more. Currently modedb is way to heavy. It needs 
to be cleaned up.



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[Benjamin Herrenschmidt]

On Wed, 2004-06-23 at 14:00, jsimmons@pentafluge.infradead.org wrote:
> > I still think (didn't I repeat it often enough) that the whole idea
> > of stty "inventing" modes based on console size is broken. We simply
> > can't rely on good enough monitor detection & mode list building to
> > be able to pick proper modes. Not only our code is far from ready for
> > that, but it will also call all sort of problems to users (remember
> > you monitors that need different subtle geometry settings for each
> > different mode you use ?)
> > 
> > It may have looked like a nice idea, but I think it's just wrong.
> 
> Its a POSIX standard. You need to yell at them. 

I don't remember seeing anything in POSIX regarding tweaking monitor
video modes ;)

> > fbset sends an ioctl straight to the fbdev, and doesn't update fbcon
> > at the moment. The callback mecanism I added for power management
> > should allow to restore 2.4 functionality there, but this has not
> > been implemented yet afaik.
> 
> It will be added back. I didn't merge the one from before because it had 
> problems. 
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[jsimmons]

> > > can't rely on good enough monitor detection & mode list building to
> > > be able to pick proper modes. Not only our code is far from ready for
> > > that, but it will also call all sort of problems to users (remember
> > > you monitors that need different subtle geometry settings for each
> > > different mode you use ?)
> > > 
> > > It may have looked like a nice idea, but I think it's just wrong.
> > 
> > Its a POSIX standard. You need to yell at them. 
> 
> I don't remember seeing anything in POSIX regarding tweaking monitor
> video modes ;)

Just do a web search on POSIX and TIOCSWINSZ.
 


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[Benjamin Herrenschmidt]

On Wed, 2004-06-23 at 15:03, jsimmons@pentafluge.infradead.org wrote:
> > > > can't rely on good enough monitor detection & mode list building to
> > > > be able to pick proper modes. Not only our code is far from ready for
> > > > that, but it will also call all sort of problems to users (remember
> > > > you monitors that need different subtle geometry settings for each
> > > > different mode you use ?)
> > > > 
> > > > It may have looked like a nice idea, but I think it's just wrong.
> > > 
> > > Its a POSIX standard. You need to yell at them. 
> > 
> > I don't remember seeing anything in POSIX regarding tweaking monitor
> > video modes ;)
> 
> Just do a web search on POSIX and TIOCSWINSZ.

And besides, that's irrelevant, especially since there are way too much
cases where we simply won't do the right thing (monitors lying about
their modes or incorrectly detected for example). There is a reason why
most OSes have this dialog asking you to confirm a resolution change and
click OK... It's fine with scaled flat panels to scale to pretty much
anything, but other cases are a bit more dodgy.

Anyway, the point is, such an option has NOTHING to do in the fbcon
layer unless we have fully implemented & properly working monitor
detection, which we are only starting to have and only in some drivers.

Ben.




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[jsimmons]

> Benjamin Herrenschmidt wrote:
> 
> >It may have looked like a nice idea, but I think it's just wrong.
> >  
> >
> I think that the implementation is wrong, not the whole idea.  Currently 
> the vt_resize ioctl changes the vt size then tries to set the resolution 
> leading to a whole bunch of problems when a suitable resolution can't be 
> found and makes the fbset result ion change code path ugly as well.
> 
> What should happen is that the vt_resize ioctl should be sent to the 
> console driver first and then the console driver calls back the vt layer 
> with the modified  row and column numbers based on the closest 
> resolution found.
> 
> So what we have right now is:
> 
> vt_ioctl (VT_RESIZE) -> vc_resize -> resize_screen -> con_resize ->  
> fb_set_var -> fbcon_event_notify -> vc_resize*

Good catch. We need a flag to determine which layer it came from. Tony 
posted a patch dealing with that.


> 
> * or equivilent code depending on who's patch you use
> 
> Which should be:
> 
> vt_ioctl (VT_RESIZE) -> resize_screen -> con_resize -> fb_set_var & 
> vc_resize
> 
> You'd have to have a per vt var in order to have different console sizes 
> on different vt's this way.  The reason for not using the 
> fbcon_event_notify is that it won't be called when the vt is not in the 
> forground and I don't belive that a we need to resize the console when 
> switching between different vt's.  A vc_resize would the be necessary in 
> the fb_ioctl FBIOPUT_VSCREENINFO code path in this case.
> 
> John
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[John Zielinski]

jsimmons@pentafluge.infradead.org wrote:

>Good catch. We need a flag to determine which layer it came from. Tony 
>posted a patch dealing with that.
>  
>
I took a look and I'm going to merge that into my kernel and trace 
trough the ioctl call paths again.  The VT_RESIZE path looks good with 
his patch but I think that the FBIOPUT_VSCREENINFO may loop through a 
few functions a second time.  I'll know for sure when I trace things out 
later.

But my thinking was that vc_resize (or part of it split of into a 
seperate function) should be the final terminus of the code path.  That 
way you wouldn't need flags or anything else to break out of the 
circular code path we have now.  The code would be easier to follow and 
be less prone to mistakes.

I'll see if I can whip up a patch that works with our current single var 
to show you what I mean.

John




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[Antonino A. Daplas]

On Thursday 24 June 2004 04:12, Benjamin Herrenschmidt wrote:
> > Just do a web search on POSIX and TIOCSWINSZ.
>
> And besides, that's irrelevant, especially since there are way too much
> cases where we simply won't do the right thing (monitors lying about
> their modes or incorrectly detected for example). There is a reason why
> most OSes have this dialog asking you to confirm a resolution change and
> click OK... It's fine with scaled flat panels to scale to pretty much
> anything, but other cases are a bit more dodgy.
>
> Anyway, the point is, such an option has NOTHING to do in the fbcon
> layer unless we have fully implemented & properly working monitor
> detection, which we are only starting to have and only in some drivers.
>

stty has its pros, such as allowing a user to at least set the video resolution
without being root.

And, of course, its cons, such as crashing the machine simply by using stty,
iff fbdev cannot handle these mode requests properly.

Tony




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Sane behavior of fbset

[Antonino A. Daplas]

On Wednesday 23 June 2004 23:55, Benjamin Herrenschmidt wrote:
> > The flow of fbset is upstream:  fbset->fbdev->fbcon->vc (2.4 code)
> > The flow of stty is downstream: stty->vc->fbcon->fbdev (2.6 code)
> >
> > I don't know how radeonfb does it though.
>
> I still think (didn't I repeat it often enough) that the whole idea
> of stty "inventing" modes based on console size is broken. We simply
> can't rely on good enough monitor detection & mode list building to
> be able to pick proper modes. Not only our code is far from ready for
> that, but it will also call all sort of problems to users (remember
> you monitors that need different subtle geometry settings for each
> different mode you use ?)
>
> It may have looked like a nice idea, but I think it's just wrong.
>

It started out like this, during 2.5 development. The discussions were
not very clear cut, as ironing bugs was the main concerned, but basically
it all boils down to the following points:

a. fbset functionality was lost (or removed), so how do we change the
resolution of fbdev?

b. what should be the correct behavior of stty?  

So there were 2 ideas:

1. An stty call will just have to modify the video mode. This will require
that fbdev must be able to handle mode change requests independently.

2. stty will just have to produce a smaller or larger viewport, without
changing the resolution of the video mode. This will involve that fbcon
must be able to do clipping, otherwise it will attempt to write past fb
memory if vc size > fbdev size.

So, I submitted 2 patches.

For 1, I added a hook for con_resize. And for 2,  I added clipping code
for all the accel_* functions, no con_resize hook.

You probably guessed correctly which got merged, 1. And 
because 1 requires fbdev to handle mode changes independently, it's
unavoidable that we need functions to help drivers validate and choose
the correct modelines.  So, EDID parsing,  GTF calculation, and mode
validation were introduced in fbmon.c

(fbset behavior remained undefined until this thread)

Tony




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com