linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] [PATCH 1/3: FBDEV: VGA State Save/Restore module

[James S. <jsi...@in...>]

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

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[James S. <jsi...@in...>]

> > G400 X server 4.0.2 ontop of VESA framebuffer.
> 
> And i suppose the VESA driver will work, right ?

I haven't tried it but I assume it does.

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Antonino D. <ad...@po...>]

On Fri, 2002-12-06 at 01:44, Sven Luther wrote: 
> On Thu, Dec 05, 2002 at 08:37:08PM +0000, James Simmons wrote:
> > 
> > > > Not really. When X closes /dev/fb then fb_release is called which if the 
> > > 
> > > That supposes X is fbdev aware (either using the fbdev driver or the
> > > UseFBDev option), right ? What if X knows nothing about fbdev, it will
> > > try restoring stuff as if it was in text mode.
> > 
> > That is what X will try. 
> 
> Mmm, is it enough for X to just save/restore the registers it modifies ?
> 
Life will be easy if native X does that always.  However, it does not
always restore all the registers it modifies. Common example, the cursor
registers.  If fbdev is also using a hardware cursor, you will see X's
cursor replacing your console's block cursor when switching from X to
the console.

Some ATI cards freezes the system when native X and fbdev are running
concurrently.

James,

Without the set_var hook 2.5 as is in 2.4, this will become more of a
problem. Most drivers in 2.4 refreshes their registers during set_var.

> Also, i suppose if i am comming from fbdev, what X saves or restores
> does not really count, since fbdev knows what relevant thing to save.

Yes, the same thing too if the X driver supports Option "Usefbdev". Instead
of restoring the hardware registers, X (or XFBdev) will call fb_set_var 
to restore fbcon's state.

> 
> Still i sense that there may be some issues involved here, especially
> if you switch from text mode to fbdev or between fbdevs while not in X.
> 

State saves and restores are pertinent only for state changes within a single card.
Ie, the state of the vga core and the graphics state. Thus, this is relevant to
vgacon, vga16fb, the native fbdev driver, and of course X since all can coexist 
in one card. I have already run vgacon, vga16fb and native fbdev simultaneously
already.  Fortunately, the X driver was nice too, so I was able to run X also.  

In multiple fbdev's with each on it's own hardware, this does not matter since 
the state of the other hopefully does not affect the other. The only problem I can think
of is that one card is the primary (thus with an active vga core) and the others are
non primary (thus with an inactive vga core).  If the non-primary drivers are not
careful, they may attempt to save/restore the VGA state that they have no business of
knowing.  There can be several solutions to this:

1.  There is probably a flag somewhere that says that the hardware's vga core is 
inactive, and if so, do not attempt to save/restore the state..

2.  Most hardware with a vga core most probably has the VGA registers memory mapped. 
If this is the case, all it needs to do is fill up fb_vgastate.vgabase, and the 
save/restore module will instead do mmio instead of pio, leaving the actual VGA registers
untouched.

Tony

Re: [Linux-fbdev-devel] [PATCH 1/3: FBDEV: VGA State Save/Restore module

[Antonino D. <ad...@po...>]

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

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Sven L. <lu...@dp...>]

On Thu, Dec 05, 2002 at 08:37:08PM +0000, James Simmons wrote:
> 
> > > Not really. When X closes /dev/fb then fb_release is called which if the 
> > 
> > That supposes X is fbdev aware (either using the fbdev driver or the
> > UseFBDev option), right ? What if X knows nothing about fbdev, it will
> > try restoring stuff as if it was in text mode.
> 
> That is what X will try. 

Mmm, is it enough for X to just save/restore the registers it modifies ?

Also, i suppose if i am comming from fbdev, what X saves or restores
does not really count, since fbdev knows what relevant thing to save.

Still i sense that there may be some issues involved here, especially
if you switch from text mode to fbdev or between fbdevs while not in X.

> > >     X on VESA fb always foobars my system when I exit X.
> > 
> > With which driver ? (i am happily running the vesa X driver on top of
> > vesafb without problems).
> 
> G400 X server 4.0.2 ontop of VESA framebuffer.

And i suppose the VESA driver will work, right ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[James S. <jsi...@in...>]

> > Not really. When X closes /dev/fb then fb_release is called which if the 
> 
> That supposes X is fbdev aware (either using the fbdev driver or the
> UseFBDev option), right ? What if X knows nothing about fbdev, it will
> try restoring stuff as if it was in text mode.

That is what X will try. 

> >     X on VESA fb always foobars my system when I exit X.
> 
> With which driver ? (i am happily running the vesa X driver on top of
> vesafb without problems).

G400 X server 4.0.2 ontop of VESA framebuffer.

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Sven L. <lu...@dp...>]

On Thu, Dec 05, 2002 at 05:35:56PM +0000, James Simmons wrote:
> 
> > If X is running  in native mode then it has to save the register state. 
> > Otherwise you cannot switch to a console.  If X is running on top of
> > fbdev, then state restore/saves are done using fb_set_var and
> > fb_get_var.  The registers are not touched, that's the purpose of fbdev.
> > 
> > If you are running vgacon, fbdev, and native X, then yes, fbdev and X
> > has to do a save of their initial state.
> 
> Not really. When X closes /dev/fb then fb_release is called which if the 

That supposes X is fbdev aware (either using the fbdev driver or the
UseFBDev option), right ? What if X knows nothing about fbdev, it will
try restoring stuff as if it was in text mode.

> driver supports it will switch back to text mode. The exception is 
> firmware based fbdev drivers like vesafb and offb.  
> 
> > > Does this also apply to vesafb ?
> > Not too sure about this. vesa requires real-mode initialization.  Either
> > you do this at boot time, or fake a real-mode environment like what X
> > does.
> 
> X has to reset the vidoe hardware back to the state that matches what the 
> VESA mode was. Other wise it will mess you your system.
> 
> P.S
> 
>     X on VESA fb always foobars my system when I exit X.

With which driver ? (i am happily running the vesa X driver on top of
vesafb without problems).

Friendly,

Sven Luther

[Linux-fbdev-devel] Re: [PATCH 1/3: FBDEV: VGA State Save/Restore module

[James S. <jsi...@in...>]

> Look at vgacon. Uses font block 0,2,3 from plane 2 when built
> without BROKEN_GRAPHICS_PROGRAMS, or 0,1 when built with 
> BROKEN_GRAPHICS_PROGRAMS. So if you want just restore vgacon environment,
> save only these 4 blocks (4*8K = 32K). Or you want to save whole
> VGA memory, and then save whole 256KB, without tricks while saving
> planes 0 & 1.

If you could get ride of the dependance on BROKEN_GRAPHICS_PROGRAM I would 
be really happy.

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[James S. <jsi...@in...>]

> If X is running  in native mode then it has to save the register state. 
> Otherwise you cannot switch to a console.  If X is running on top of
> fbdev, then state restore/saves are done using fb_set_var and
> fb_get_var.  The registers are not touched, that's the purpose of fbdev.
> 
> If you are running vgacon, fbdev, and native X, then yes, fbdev and X
> has to do a save of their initial state.

Not really. When X closes /dev/fb then fb_release is called which if the 
driver supports it will switch back to text mode. The exception is 
firmware based fbdev drivers like vesafb and offb.  

> > Does this also apply to vesafb ?
> Not too sure about this. vesa requires real-mode initialization.  Either
> you do this at boot time, or fake a real-mode environment like what X
> does.

X has to reset the vidoe hardware back to the state that matches what the 
VESA mode was. Other wise it will mess you your system.

P.S

    X on VESA fb always foobars my system when I exit X.

Re: [Linux-fbdev-devel] [PATCH 1/3: FBDEV: VGA State Save/Restore module

[James S. <jsi...@in...>]

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

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Greg H. <gr...@ce...>]

> I question whether thats something that belongs anywhere near the
> kernel. Ben Pfaff wrote a fine library for vga16 hackery (BOGL) and it
> combines very nicely with the fb driver.

> Out of curiousity where is this library.

BOGL is referenced at http://www.msu.edu/user/pfaffben/projects.html
but I think it's not maintained anymore.  I used BOGL originally,
and used it for a complete rewrite of a VGA16 driver for Microwindows,
with a C version for Linux framebuffer..
See http://microwindows.org Source Code for more details.

Regards,

Greg
Founder & Maintainer, The Microwindows Project

[Linux-fbdev-devel] [PATCH] FBDEV: VGA Save/Restore module - round 2

[Antonino D. <ad...@po...>]

Hi,

Attached is an updated patch against linux-2.5.50 + James Simmons'
fbdev.diff.  Most of the changes are as per suggestions by Petr
Vandrovec (Thanks!) targeted towards selective saves/and restores
specific to the setting of vgacon.

Tested drivers:

vga16fb using VGA_SAVE_CMAP | VGA_SAVE_MODE flags will correctly restore
VGA text mode and high resolution graphics mode.

rivafb (riva128) using VGA_SAVE_CMAP |  VGA_SAVE_MODE | VGA_SAVE_FONT0
flags effectively restores VGA text and graphics mode with minor screen
corruption.

Tony

PS: Please reverse previous patches (vgastate.diff and vgastate1.diff)
if applied.

[Linux-fbdev-devel] Re: [PATCH 1/3: FBDEV: VGA State Save/Restore module

[Petr V. <van...@vc...>]

On Thu, Dec 05, 2002 at 07:53:16AM +0500, Antonino Daplas wrote:
> On Thu, 2002-12-05 at 03:33, Petr Vandrovec wrote:
> > On  5 Dec 02 at 6:05, Antonino Daplas wrote:
> > planes 0 & 1.
> 
> Okay, then.  My approach was to be non-vgacon specific.  I'll do it to
> specifically target vgacon then.
> 
> To summarize:
> plane 0/1 save 8K at offset 0 and 8K at offset 16K;

I'm not sure about this one. AFAIK by default vgacon uses first 32KB
completely (every second byte...) from both 0/1, and can be configured
(by enabling VGA_CAN_DO_64KB) to use full 64KB.

> plane 2   save 32K at offset 0 (covers blocks 0-3),
> plane 3   same for plane 2
> 
> Drivers can set VGA_SAVE_TEXT | VGA_SAVE_FONT0 to save planes 0-2.  If
> there are no complaints, I'll  proceed doing it this way.

I have no other problems.
						Petr Vandrovec
						van...@vc...

[Linux-fbdev-devel] Re: [PATCH 1/3: FBDEV: VGA State Save/Restore module

[Antonino D. <ad...@po...>]

On Thu, 2002-12-05 at 03:33, Petr Vandrovec wrote:
> On  5 Dec 02 at 6:05, Antonino Daplas wrote:
> > On Wed, 2002-12-04 at 23:41, Petr Vandrovec wrote:
> > > On  4 Dec 02 at 22:26, Antonino Daplas wrote:
> > [...]
> > > And if my VGA documentation is correct, you are saving random
> > > data into vga_text: first 8192 chars interleaved with
> > > 8192 bytes of garbage, plus attributes from chars 8192-16383 interleaved
> > > with 8192 bytes of garbage. 
> > >
> > Right, I'm not sure about this part too.  The docs say that this is true
> > for EGA compatible hardware.  How about non-compliant hardware?  
> 
> Like non-VGA? Like CGA/MDA? I thought that non-VGA/non-EGA adapters are 
> out of scope of this document ;-)
>   
Okay :-), as I've said this is the part I'm not sure of.  I'll do it
your way then, save 8K at offset 0 and save 8K at offset 16K.  That
should be 16K used instead of 32K, right?

> > > And if you are using standard hardware, then font data live only in
> > > plane 2, plane 3 is unused on VGA hardware in text mode. I think that
> > > you should either save whole 256KB of memory, without deeper understanding,
> > > or you should just save FONT 0 (first 32*256 bytes from plane 2) if you
> 
> > Only if saving the first character map in plane 2.  Hardware can have as
> > much as 8 character maps per plane, each 8K in size for 64K.  The same
> > setup is true for plane 3 fonts.
> 
> How you select them? Mine doc says that font block 0 begins in plane 2
> at offset 0, block 1 at offset 16KB, 2 at 32K, 3 at 48K, 4 at 8K, 5 at 24K,
> 6 at 40K, and last, 7th, at 56KB, and sequencer has two threebit fields...
> 
Selection was not the problem, the code just saves the entire 64K for
character maps 0-7.

> > > want to save memory and you know that console was driven by vgacon in
> > > text mode.
> > To save memory, apps can explicitly choose what to save, but I don't
> > want to go finer than that, ie. save character maps 2,3,5  of plane 2
> > and 1,2,3 of plane 3.  The current way of saving the text mode map may
> > be a bit wasteful, but better than being bitten by hardware that's
> > non-EGA compliant.  
> 
> Look at vgacon. Uses font block 0,2,3 from plane 2 when built
> without BROKEN_GRAPHICS_PROGRAMS, or 0,1 when built with 
> BROKEN_GRAPHICS_PROGRAMS. So if you want just restore vgacon environment,
> save only these 4 blocks (4*8K = 32K). Or you want to save whole
> VGA memory, and then save whole 256KB, without tricks while saving
> planes 0 & 1.

Okay, then.  My approach was to be non-vgacon specific.  I'll do it to
specifically target vgacon then.

To summarize:
plane 0/1 save 8K at offset 0 and 8K at offset 16K;
plane 2   save 32K at offset 0 (covers blocks 0-3),
plane 3   same for plane 2

Drivers can set VGA_SAVE_TEXT | VGA_SAVE_FONT0 to save planes 0-2.  If
there are no complaints, I'll  proceed doing it this way.

Thanks for the input Petr.

Tony

Re: [OT] Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[James S. <jsi...@in...>]

> On Wed, 4 Dec 2002, Petr Vandrovec wrote:
> > FYI, I'm going to unsubscribe myself from linux-fbdev-devel.
> > I'm not interested in reading messages on list which is not public:
> > I get again an error that my message is waiting for moderator approval,
> > and as such list is unsuitable for any realtime discussion.
>
> Yes, I know it's annoying :-(
>
> But, AFAIK we don't know yet
>   1. who changed the list to a moderated list
>   2. who is actually moderating it

I'm also perturbed by this. I guess we need to apporach sourceforge to ask
the list passwords to be changed so we can mange the list ourselves.

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[James S. <jsi...@in...>]

> Here's a preliminary and highly unpolished patch for saving and
> restoring the initial vga state.

Totally awesome!!! About a year ago I also manged to do this while working
on the ruby linuxconsole project. I'm glad to see it resurrected again!!!!
Looking at the code I see both of us have the same ideas.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

[Linux-fbdev-devel] Re: [PATCH 1/3: FBDEV: VGA State Save/Restore module

[Petr V. <VAN...@vc...>]

On  5 Dec 02 at 6:05, Antonino Daplas wrote:
> On Wed, 2002-12-04 at 23:41, Petr Vandrovec wrote:
> > On  4 Dec 02 at 22:26, Antonino Daplas wrote:
> [...]
> > And if my VGA documentation is correct, you are saving random
> > data into vga_text: first 8192 chars interleaved with
> > 8192 bytes of garbage, plus attributes from chars 8192-16383 interleaved
> > with 8192 bytes of garbage. 
> >
> Right, I'm not sure about this part too.  The docs say that this is true
> for EGA compatible hardware.  How about non-compliant hardware?  

Like non-VGA? Like CGA/MDA? I thought that non-VGA/non-EGA adapters are 
out of scope of this document ;-)
  
> > And if you are using standard hardware, then font data live only in
> > plane 2, plane 3 is unused on VGA hardware in text mode. I think that
> > you should either save whole 256KB of memory, without deeper understanding,
> > or you should just save FONT 0 (first 32*256 bytes from plane 2) if you

> Only if saving the first character map in plane 2.  Hardware can have as
> much as 8 character maps per plane, each 8K in size for 64K.  The same
> setup is true for plane 3 fonts.

How you select them? Mine doc says that font block 0 begins in plane 2
at offset 0, block 1 at offset 16KB, 2 at 32K, 3 at 48K, 4 at 8K, 5 at 24K,
6 at 40K, and last, 7th, at 56KB, and sequencer has two threebit fields...

> > want to save memory and you know that console was driven by vgacon in
> > text mode.
> To save memory, apps can explicitly choose what to save, but I don't
> want to go finer than that, ie. save character maps 2,3,5  of plane 2
> and 1,2,3 of plane 3.  The current way of saving the text mode map may
> be a bit wasteful, but better than being bitten by hardware that's
> non-EGA compliant.  

Look at vgacon. Uses font block 0,2,3 from plane 2 when built
without BROKEN_GRAPHICS_PROGRAMS, or 0,1 when built with 
BROKEN_GRAPHICS_PROGRAMS. So if you want just restore vgacon environment,
save only these 4 blocks (4*8K = 32K). Or you want to save whole
VGA memory, and then save whole 256KB, without tricks while saving
planes 0 & 1.
                                            Petr Vandrovec
                                            van...@vc...
                                            

Re: [Linux-fbdev-devel] aty support

[James S. <jsi...@in...>]

> You may want to try the atyfb patches from Dani=EBl Mantione
> <da...@de...>,

O!!! I like to havbe those as well.

[Linux-fbdev-devel] Re: [PATCH 1/3: FBDEV: VGA State Save/Restore module

[Antonino D. <ad...@po...>]

On Wed, 2002-12-04 at 23:41, Petr Vandrovec wrote:
> On  4 Dec 02 at 22:26, Antonino Daplas wrote:
> > +static void vga_cleanup(struct fb_vgastate *state)
> > +{
> > +   if (state->fbbase)
> > +       iounmap(state->fbbase);
> > +}
> 
> Nobody is setting state->fbbase to NULL, so 
Oops, yes I missed setting fbbase to NULL at the start.

> "save_vga(SAVE_FONT); restore_vga(); save_vga(0); restore_vga();"
> will badly die. I think that you should change save prototype to
> int fb_save_vga(int whattosave, struct fb_vgastate* state);, and at
> the beginning of save you should do "memset(state, 0, sizeof(*state));"
> 
> And fbbase should not be in state variable, as this value is valid
> only during duration of save or restore, not outside of them. Pass it
> to function which needs it as an explicit argument.
>
The field fbbase is kind of temporary at the moment, fixed for the
0xa0000 window.  I'm currently thinking of having the offset and the
size of the window optionally set by the calling process.
 
> It looks easier to me to make fb_vgastate larger structure with
> crt/seq/cmap fields embeded, instead of kmallocing these portions.
> Or at least allocate them together depending on 'whattosave' flag,
> doing four kmalloc() to allocate about 64 bytes is waste of resources.

I hate hardwiring fixed numbers :)  It's also possible that some drivers
may find it sufficient to use the module to save the standard and its
own set of extended registers. 

But you're correct, 4 kmallocs is wasteful, I wasn't thinking straight
:-).  I'll just do one and adjust the offsets for each field.

[...]
> And if my VGA documentation is correct, you are saving random
> data into vga_text: first 8192 chars interleaved with
> 8192 bytes of garbage, plus attributes from chars 8192-16383 interleaved
> with 8192 bytes of garbage. 
>
Right, I'm not sure about this part too.  The docs say that this is true
for EGA compatible hardware.  How about non-compliant hardware?  
 
> When you program hardware to get access to planes (vga 16 color 
> graphics mode), every second byte from plane 0 contains character, 
> and every second byte from plane 1 contains character attribute 
> (it is that way because of bit A0 selects plane, while A15-A1.0 
> selects memory address, so odd in memory addresses are unreachable 
> in vga text mode).
> 
> And if you are using standard hardware, then font data live only in
> plane 2, plane 3 is unused on VGA hardware in text mode. I think that
> you should either save whole 256KB of memory, without deeper understanding,
> or you should just save FONT 0 (first 32*256 bytes from plane 2) if you
Only if saving the first character map in plane 2.  Hardware can have as
much as 8 character maps per plane, each 8K in size for 64K.  The same
setup is true for plane 3 fonts.
 
> want to save memory and you know that console was driven by vgacon in
> text mode.
To save memory, apps can explicitly choose what to save, but I don't
want to go finer than that, ie. save character maps 2,3,5  of plane 2
and 1,2,3 of plane 3.  The current way of saving the text mode map may
be a bit wasteful, but better than being bitten by hardware that's
non-EGA compliant.  

Tony
 

[Linux-fbdev-devel] Re: console_struct.h:97: `MAX_NR_CONSOLES' undeclared here

[James S. <jsi...@in...>]

Okay. I applied a fix. I will push it soon.

> gcc -Wp,-MD,kernel/.suspend.o.d -D__KERNEL__ -Iinclude -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
> -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=athlon
> -Iarch/i386/mach-generic -nostdinc -iwithprefix include
> -DKBUILD_BASENAME=suspend -DKBUILD_MODNAME=suspend -DEXPORT_SYMTAB  -c
> -o kernel/suspend.o kernel/suspend.c
> In file included from include/linux/vt_kern.h:12,
>                  from kernel/suspend.c:46:
> include/linux/console_struct.h:97: `MAX_NR_CONSOLES' undeclared here
> (not in a function)
> kernel/suspend.c:294:2: warning: #warning This might be broken. We need
> to somehow wait for data to reach the disk
> kernel/suspend.c: In function `count_and_copy_data_pages':
> kernel/suspend.c:516: warning: passing arg 1 of `mmx_copy_page' makes
> pointer from integer without a cast
> kernel/suspend.c:516: warning: passing arg 2 of `mmx_copy_page' makes
> pointer from integer without a cast
> make[2]: *** [kernel/suspend.o] Error 1
>
> CONFIG_MK7=y
>
> #
> # Graphics support
> #
> CONFIG_FB=y
> # CONFIG_FB_CLGEN is not set
> # CONFIG_FB_PM2 is not set
> # CONFIG_FB_CYBER2000 is not set
> # CONFIG_FB_IMSTT is not set
> # CONFIG_FB_VGA16 is not set
> CONFIG_FB_VESA=y
> CONFIG_VIDEO_SELECT=y
> # CONFIG_FB_HGA is not set
> CONFIG_FB_RIVA=y
>
> CONFIG_VGA_CONSOLE=y
> # CONFIG_MDA_CONSOLE is not set
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_PCI_CONSOLE=y
> # CONFIG_FBCON_ADVANCED is not set
> # CONFIG_FONTWIDTH8_ONLY is not set
> # CONFIG_FONTS is not set
> CONFIG_FONT_8x8=y
> CONFIG_FONT_8x16=y
>
>
>
>

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Antonino D. <ad...@po...>]

On Wed, 2002-12-04 at 21:47, Sven Luther wrote:
> > > So there is no common zqy of doing this, my docs say something about a
> > > vga control register zhich is accesses trough the sequencer regs. Does
> > > vgafb (or textmode or whatever) not call this when giving the hand to
> > > the fbdev ?
> > No, when a video card goes to graphics mode, it's up to the driver to
> > program the registers.  vgacon/vga16fb only touches the standard VGA
> 
> So we will have a repeat of the exact same code snipplet in all the
> drivers ? I thought the new API was about having all the common code in
> common and not duplicated in all the drivers. Could we have at least a
> gen_disable_vga function or something such that we could call ?

Not exactly.  Different hardware programs those registers differently.
Ie, vga will probably program the crtc regs for 640x400@60.  Your
hardware can probably do better than that. So the code cannot be
shared.  However, saving and restoring the standard VGA regs can be
common.

> 
> > registers (crtc[25], attr[21], seq[5], gfx[9], misc[1]). Usage is pretty
> 
> Well, i need to disable the vga output in seq[5], more exactly bit 3
> called "enable VGA display", need to be reset.
> 
[...]
> 
> Err, it is seq[5], called VGAControlRegister, so it is beyond the
> standard seq registers (seq[0] to seq[5]), right ?

I meant seq[0] to seq[4] are standard VGA regs.  So seq[5] is extended. 
It's VGAControlRegister in your hardware, it's not used in mine.

> 
[...]
> > > Mmm, what about interaction with X ? X also does a save/restore of the
> > > previous (text) mode, when a X driver is _not_ fbdev aware, it will
> > > save/restore the things twice, right ?
> > > 
> > Not twice just the current mode it was in when X launched, although it
> > always assumes text mode.  Same thing for fbdev, it should only restore
> 
> Well, but fbdev will save its state and X will save it again, so the
> saving done in the X driver is not all that important, and i could
> ignore it at first if i already have an fbdev.

If X is running  in native mode then it has to save the register state. 
Otherwise you cannot switch to a console.  If X is running on top of
fbdev, then state restore/saves are done using fb_set_var and
fb_get_var.  The registers are not touched, that's the purpose of fbdev.

If you are running vgacon, fbdev, and native X, then yes, fbdev and X
has to do a save of their initial state.

> 
> Does this also apply to vesafb ?
Not too sure about this. vesa requires real-mode initialization.  Either
you do this at boot time, or fake a real-mode environment like what X
does.

> 
> > the state when reference count becomes zero. If the framebuffer console
> > is loaded, the reference count will never be zero unless it is
> > unloaded.  If the framebuffer console is not loaded, the only time you
> > will save and restore the state is when some fb-based application
> > attempts to open/close /dev/fbx.
> 
> Ok, ...
> 
[...]

Tony

Re: [Linux-fbdev-devel] aty support

[James S. <jsi...@in...>]

> Can you tell me,
>
>    a) is my chipset compatible with the atyfb/aty128fb driver ?

atyfb

>    b) what todo exactly to get it working ?
>    (i know howto compile kernel, patch around code,...
>    what I need are informations, whether
>    append="video=aty128fb:accel,<640x480@8bpp>"
>    or
>    append="video=atyfb:<800x600-16bpp>"
>
>    are correct, whether to pass vga= options to the kernel
>    is senseful and so on...)

Can you try my patch at

http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

[Linux-fbdev-devel] Re: [STATUS] fbdev api.

[James S. <jsi...@in...>]

> Can you apply the following patch to include logo drawing support for all formats :-)?

Applied :-)

> It's not the switch back to text mode, that's very doable (see my other
> reply).  It's during give_up_console() at fbcon module exit.  At this
> point, the console suddenly disappears and freezes the system.  Maybe we
> can save the global "conswitchp" during fbcon module init, then
> something like this at fbcon module exit:
>
> void __exit fb_console_exit(void)
> {
> 	give_up_console(&fbcon);
> 	take_over_console(saved_conswitchp, ...);
> }
>
> Is this feasible?

I thought about it but the solution is not easy. Consider that we have
vgacon and mdacon. Then I load in hgafb. Here the goal is to take over
mdacon. So we have to prevent taking over vgacon. Since there is only on
conswitchp we are in trouble.

[Linux-fbdev-devel] Re: [PATCH 1/3: FBDEV: VGA State Save/Restore module

[Petr V. <VAN...@vc...>]

On  4 Dec 02 at 22:26, Antonino Daplas wrote:
> +static void vga_cleanup(struct fb_vgastate *state)
> +{
> +   if (state->fbbase)
> +       iounmap(state->fbbase);
> +}

Nobody is setting state->fbbase to NULL, so 
"save_vga(SAVE_FONT); restore_vga(); save_vga(0); restore_vga();"
will badly die. I think that you should change save prototype to
int fb_save_vga(int whattosave, struct fb_vgastate* state);, and at
the beginning of save you should do "memset(state, 0, sizeof(*state));"

And fbbase should not be in state variable, as this value is valid
only during duration of save or restore, not outside of them. Pass it
to function which needs it as an explicit argument.

It looks easier to me to make fb_vgastate larger structure with
crt/seq/cmap fields embeded, instead of kmallocing these portions.
Or at least allocate them together depending on 'whattosave' flag,
doing four kmalloc() to allocate about 64 bytes is waste of resources.

And do not use kmalloc() for > 4KB regions, use vmalloc (in
fonts save).

> +       state->attr = kmalloc(state->num_attr, GFP_KERNEL);
> +       state->crtc = kmalloc(state->num_crtc, GFP_KERNEL);
> +       state->gfx = kmalloc(state->num_gfx, GFP_KERNEL);
> +       state->seq = kmalloc(state->num_seq, GFP_KERNEL);
...
> +       state->vga_font0 = kmalloc(8192 * 8, GFP_KERNEL);
...
> +       state->vga_font1 = kmalloc(8192 * 8, GFP_KERNEL);
...
> +       state->vga_text = kmalloc(8192 * 4, GFP_KERNEL);

And if my VGA documentation is correct, you are saving random
data into vga_text: first 8192 chars interleaved with
8192 bytes of garbage, plus attributes from chars 8192-16383 interleaved
with 8192 bytes of garbage. 

When you program hardware to get access to planes (vga 16 color 
graphics mode), every second byte from plane 0 contains character, 
and every second byte from plane 1 contains character attribute 
(it is that way because of bit A0 selects plane, while A15-A1.0 
selects memory address, so odd in memory addresses are unreachable 
in vga text mode).

And if you are using standard hardware, then font data live only in
plane 2, plane 3 is unused on VGA hardware in text mode. I think that
you should either save whole 256KB of memory, without deeper understanding,
or you should just save FONT 0 (first 32*256 bytes from plane 2) if you
want to save memory and you know that console was driven by vgacon in
text mode.
                                                Petr Vandrovec
                                                van...@vc...
                                                

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Sven L. <lu...@dp...>]

On Wed, Dec 04, 2002 at 10:27:21PM +0500, Antonino Daplas wrote:
> On Wed, 2002-12-04 at 15:28, Sven Luther wrote:
> > > 
> > > Most cards with a VGA core needs to disable the VGA output before going
> > > to graphics mode.  Disabling VGA output is hardware specific, and is
> > > usually automatic when you go to graphics mode.
> > 
> > So there is no common zqy of doing this, my docs say something about a
> > vga control register zhich is accesses trough the sequencer regs. Does
> > vgafb (or textmode or whatever) not call this when giving the hand to
> > the fbdev ?
> No, when a video card goes to graphics mode, it's up to the driver to
> program the registers.  vgacon/vga16fb only touches the standard VGA

So we will have a repeat of the exact same code snipplet in all the
drivers ? I thought the new API was about having all the common code in
common and not duplicated in all the drivers. Could we have at least a
gen_disable_vga function or something such that we could call ?

> registers (crtc[25], attr[21], seq[5], gfx[9], misc[1]). Usage is pretty

Well, i need to disable the vga output in seq[5], more exactly bit 3
called "enable VGA display", need to be reset.

> much uniform across all hardware. Any registers past those indices are
> considered extended registers and usage is hardware specific.  In
> graphics mode, you will probably use both the standard and the extended
> registers, and disabling the VGA mode/enabling graphics mode is most
> probably in one of the extended registers.

Err, it is seq[5], called VGAControlRegister, so it is beyond the
standard seq registers (seq[0] to seq[5]), right ?

> > > Because James wrote the fb framework to be very modular, then you must
> > > be careful to save/restore the initial video state  when loading or
> > > unloading.  Theoretically, a driver should load, but not go to graphics
> > > mode immediately.  Only upon a call to xxxfb_set_par() should the driver
> > > do so.  Before going to graphics mode, that's were you save the initial
> > > state.  Have a reference count or something to keep track of the number
> > > of users, and when this reference count becomes zero, restore the
> > > initial state.  You should be able to do this by hooking these routines
> > > in fb_open() and fb_release().
> > 
> > Mmm, what about interaction with X ? X also does a save/restore of the
> > previous (text) mode, when a X driver is _not_ fbdev aware, it will
> > save/restore the things twice, right ?
> > 
> Not twice just the current mode it was in when X launched, although it
> always assumes text mode.  Same thing for fbdev, it should only restore

Well, but fbdev will save its state and X will save it again, so the
saving done in the X driver is not all that important, and i could
ignore it at first if i already have an fbdev.

Does this also apply to vesafb ?

> the state when reference count becomes zero. If the framebuffer console
> is loaded, the reference count will never be zero unless it is
> unloaded.  If the framebuffer console is not loaded, the only time you
> will save and restore the state is when some fb-based application
> attempts to open/close /dev/fbx.

Ok, ...

> > > The one I submitted (and a revised one I'm going to submit soon) should
> > > be able to restore the VGA text/graphics mode.  Complement this with
> > > your hardware's extended state save and restore routines and you should
> > > be able to load/use/unload your driver repeatedly :-).
> > 
> > Ok, i will try.
> 
> This is optional though.  You can still adopt the 2.4 method of always
> setting the video mode.  Just take note that fbdev can be loaded without
> fbcon, and if you get into graphics mode without fbcon, you just messed
> up your user's console.  I think this can be avoided by munging the
> configuration file (ie, always depend on fbcon and make your module
> unsafe to unload).

Anyway, i need to play with it some and experiment before i can do more
comments.

Friendly,

Sven Luther