Index:
[thread]
[date]
[subject]
[author]
From: Andreas Beck <becka@rz.uni-duesseldorf.de>
To : ggi-develop@eskimo.com
Date: Wed, 18 Aug 1999 23:38:11 +0200
Re: VC Switching
> switch. I'm saying is that with /dev/fb open and mmap that a vt switch
> then is impractical unless you drop the mmap image each time. Now their
> will be some users that want the kernel to save this image.
Unless something has changed severely since the 1.2 kernel series, which is
the last time I checked, This is plain impossible.
VT switching comes in in interrupt context. The kernel has no access to
swappable memory in there (which makes sense), thus it can't save away huge
data areas without explicit help from usermode or maybe a kernel thread (I'm
not up to speed on those).
I'll quickly outline the RAMDAEMON approach scrdrv 0.0.7 had, to see what
that means:
1. You start up the RAMDAEMON.
2. It registers with the kernel to be the VT-switch-allowing entity.
3. A VT switch comes in. In interrupt context.
4. We send a singal to the RAMDAEMON and exit interrupt context
without VT-switching.
5. The RAMDAEMON gets scheduled and saves away the video RAM.
6. It makes it accessible to the application via shmem.
7. The RAMDAEMON calls back the kernel that it grants the switch request.
8. The kernel unmaps the framebuffer. Further access will yield SIGSEGV.
9. The kernel switches VTs.
The application has not yet seen a change.
10. The application accesses the framebuffer. => SIGSEV.
11. The application catches SEGV and checks with the kernel, if it was due
to a backgrounded framebuffer access. If yes, the application in-situ
remap its buffers to the shmem area. If no, it falls back the handler
chain and faults.
Switchback works similar.
But as said, the main problem is not the fb-image, but the card state, which
cannot be clearly determined on almost any card (except for those that
were designed for it) _anytime_. Most of the time yes, but not when accel
access is ongoing.
CU, ANdy
--
= Andreas Beck | Email : <andreas.beck@ggi-project.org> =
Index:
[thread]
[date]
[subject]
[author]