Messages in this thread | | | Date | Tue, 23 Jun 1998 16:10:43 -0700 (PDT) | From | "Jon M. Taylor" <> | Subject | Re: Resume/Suspend (was Re: LVM / Filesystems / High availability) |
| |
On Wed, 24 Jun 1998, Magnus Redin wrote:
> > > Hey, there's a thought! That is a good idea.Almost mainframe like in > > recovery... X is a no-go with this, though. You need to save the > > complete state of a SVGA card. Thoughts? > > -Shawn > > It should be enough to ask the X-server to redraw the screen.
Nope, that is not enough with most SVGA cards. Since many VGA registers are write-only, X has to keep softcopies of those regs in order to be kept aware of exactly what state the video hardware is in. If you checkpoint the X server, run some other video card banging program like SVGALib or Suid-KGI or even another X server, and then restart the old X server, its register softcopies may not any longer correspond to the actual state of the hardware = problems.
There is also the issue of atomicity of accelerator commands - a lot of cards don't take well to being interrupted whilst their accel command FIFOs are half full of command words. Even if the next bit of code that hits the video card after X is checkpointed in this case doesn't cause the card to barf and lock the bus, what happens when the X server is restarted and finishes filling the FIFOs with the rest of the accel command words, producing at best a garbled display and at worst DMAing garbage all over the kernel's address space? Fun times.
If the video drivers were in the kernel, OTOH, you could indeed just ask the X server to redraw the screen and everything would work OK since both softcopying and atomicity would be handled by the video drivers. With LibGGI, you'd just have the restarter send SIGWINCH to the restarted X server (or any other app) and it would be treated the same way as if a VT switch had occured and redraw its display.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |