[PATCH 1/3: FBDEV: VGA State Save/Restore module

Hi,

Attached is a patch against linux-2.5.50 + James Simmons fbdev.diff to
save and restore the VGA state. This includes character maps (plane
0-3), the colormap, and the video mode.  This can be used in fb_open()
and fb_release() to go back to VGA text/graphics mode.

Usage:

struct fb_vgastate state;

/* To save VGA state */
state.flags = VGA_SAVE_MODE | VGA_SAVE_CMAP | VGA_SAVE_FONTS;
fb_save_vga(&state);

/* To restore VGA state */
fb_restore_vga(&state);

Limitations:
1.  Restoring the VGA state from high-resolution graphics mode may
result in a corrupt display which can be corrected by switching
consoles.  May need a screen redraw at this point.  Restoring from VGA
graphics mode to text mode and vice versa is okay.

2. Assumes some things about the hardware which is not universally
correct:  VGA memory base is at 0xA0000, memory size is 64KB, the
hardware palette is readable, etc. 

Any comments welcome.

Tony

PS:  Please reverse the early patch I submitted if it was applied --
vgastate.diff

Limitations:
1.  Restoring the VGA state from high-resolution graphics mode may
result in a corrupt display which can be corrected by switching
consoles.  May need a screen redraw at this point.  Restoring from VGA
graphics mode to text mode and vice versa is okay.

2. Assumes some things about the hardware which is not universally
correct:  VGA memory base is at 0xA0000, memory size is 64KB, the
hardware palette is readable, etc. 

Any comments welcome.

One thing I like to suggest. I like to move the vga code in fb.h to vga.h. 
Alot of fbdev devices don't have a VGA core. 

On Thu, 2002-12-05 at 22:31, James Simmons wrote:

quoted

Limitations:
1.  Restoring the VGA state from high-resolution graphics mode may
result in a corrupt display which can be corrected by switching
consoles.  May need a screen redraw at this point.  Restoring from VGA
graphics mode to text mode and vice versa is okay.

2. Assumes some things about the hardware which is not universally
correct:  VGA memory base is at 0xA0000, memory size is 64KB, the
hardware palette is readable, etc. 

Any comments welcome.

One thing I like to suggest. I like to move the vga code in fb.h to vga.h. 
Alot of fbdev devices don't have a VGA core. 

Only the structure definition of fb_vgastate is in fb.h.  For drivers
without a vga core, they'll just won't link to it and it won't be
compiled.  Plus, vga.h is not a common header (not located in
include/asm or include/linux) and it contains a lot of declarations and
definitions which are irrelevant to most drivers or are already
duplicated.  This will be messier, I think.  

Maybe we can just enclose it in a macro, something like:

#ifdef FBDEV_HAS_VGACORE
...
#endif

Tony

quoted

One thing I like to suggest. I like to move the vga code in fb.h to vga.h. 
Alot of fbdev devices don't have a VGA core. 

Only the structure definition of fb_vgastate is in fb.h.  For drivers
without a vga core, they'll just won't link to it and it won't be
compiled.  Plus, vga.h is not a common header (not located in
include/asm or include/linux) and it contains a lot of declarations and
definitions which are irrelevant to most drivers or are already
duplicated.  This will be messier, I think.  

I like to move vga.h to include/video. And yes I like to clean it up. The 
reason is I like to implement the function in vga.h and some in vgastate 
into vgacon.c. It would be nice if vgacon could support different hardware 
states per VC instead of changing every virtual console for everything. 
The other dream is I like to see vgacon become firmware independent. 

Maybe we can just enclose it in a macro, something like:

#ifdef FBDEV_HAS_VGACORE
...
#endif

 
Yuck :-(

On Fri, 2002-12-06 at 05:53, James Simmons wrote:

quoted

Only the structure definition of fb_vgastate is in fb.h.  For drivers
without a vga core, they'll just won't link to it and it won't be
compiled.  Plus, vga.h is not a common header (not located in
include/asm or include/linux) and it contains a lot of declarations and
definitions which are irrelevant to most drivers or are already
duplicated.  This will be messier, I think.  

I like to move vga.h to include/video. And yes I like to clean it up. The 
reason is I like to implement the function in vga.h and some in vgastate 
into vgacon.c. It would be nice if vgacon could support different hardware 
states per VC instead of changing every virtual console for everything. 
The other dream is I like to see vgacon become firmware independent. 

OK.

Tony