Sane behavior of fbset

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

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

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

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

On Saturday 19 June 2004 01:38, David Eger wrote:

On Fri, Jun 18, 2004 at 09:45:12AM +0800, Antonino A. Daplas wrote:

quoted

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

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

On Saturday 19 June 2004 11:16, David Eger wrote:

On Sat, Jun 19, 2004 at 02:40:46AM +0800, Antonino A. Daplas wrote:

quoted

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

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

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

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

On Wed, 23 Jun 2004, Benjamin Herrenschmidt wrote:

quoted

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

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

quoted

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

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

quoted

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

On Wed, 23 Jun 2004 jsimmons@pentafluge.infradead.org wrote:

quoted

quoted

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.

quoted

quoted

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

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

quoted

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

On Wed, 23 Jun 2004 jsimmons@pentafluge.infradead.org wrote:

quoted

quoted

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

quoted

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

On Wed, 2004-06-23 at 14:00, jsimmons@pentafluge.infradead.org wrote:

quoted

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 ;)

quoted

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 [off-list ref]



-------------------------------------------------------
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

quoted

quoted

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

On Wed, 2004-06-23 at 15:03, jsimmons@pentafluge.infradead.org wrote:

quoted

quoted

quoted

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

Benjamin Herrenschmidt wrote:

quoted

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

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

On Thursday 24 June 2004 04:12, Benjamin Herrenschmidt wrote:

quoted

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

On Wednesday 23 June 2004 23:55, Benjamin Herrenschmidt wrote:

quoted

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