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