|
From: Antonino D. <ad...@po...> - 2002-12-04 14:35:43
Attachments:
vgastate1.diff
|
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 |
|
From: James S. <jsi...@in...> - 2002-12-05 17:32:28
|
> 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. |
|
From: Antonino D. <ad...@po...> - 2002-12-05 22:25:31
|
On Thu, 2002-12-05 at 22:31, James Simmons wrote: > > > 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 |
|
From: James S. <jsi...@in...> - 2002-12-06 00:54:48
|
> > 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 :-( |
|
From: Antonino D. <ad...@po...> - 2002-12-06 12:35:05
|
On Fri, 2002-12-06 at 05:53, James Simmons wrote: > > > > 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 |