From: James Simmons <jsimmons@edgeglobal.com>
  To  : ggi-develop@eskimo.com
  Date: Tue, 10 Aug 1999 15:01:04 -0400 (EDT)

Re: Accels and /dev/gfx.

On Mon, 9 Aug 1999, Andreas Beck wrote:

> > No. That not why VC is disabled.  Its just to impractical to store a mmap
> > image of /dev/fb on a VT switch. 
> 
> The only reasonable solution is to have a reliable protocol that handles
> VT-switches. The application should be notified of requested VT-switches,
> and it should free the device ASAP. Then the application can decide, if it
> needs to save away the display.

This is in the works. I agree with the above. The application if it wants
to when it gets a VT switch signal switch if it wants. If it does then
save a image of /dev/fb to soem file or memory and then close /dev/fb.
Once /dev/fb is closed then you can vt switch. 

> However, as this could lead to an application hogging the display (which it
> can anyway due to that insane RAW mode stuff, which is only o.k. due to
> SAK), one should as well have a force-switch SAK, which will suspend the
> application and simply ditch the framebuffer.

Alt-SysRq-k works. I have used it many times. True it would have to be
modified to close /dev/fb. 

>  General card state should be
> saved if possible. Most apps will automatically recover from that situation,
> when they get forced to do a complete redraw, which is almost always
> possible relatively easily. Recovering from a fscked card setup would be
> harder.

I agree. That one of agruement for /dev/gfx is to save the card states.
Especially on context switches.

> 
> CU, ANdy
> 
> -- 
> = Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =
>