Christoph Egger <[EMAIL PROTECTED]> wrote: > > I remember early versions of LibGGI using that to do some mmap-magic > > that copid the framebuffer to memory and then placed the memory > > buffer right at the place where the FB just was. Moreover it reset > > the accel hooks and thus fell back to software drawing while > > switched away. > That's exactly, what I proposed by using the memory target. See my > other mail.
Yeah. If you want to make the experience yourself, feel free to do so. Otherwise I'd say: Just believe me, that thing is a real PITA. > For users/applications, who don't wanna have this "fall back feature" > (see Jos reply to my mail), can pass an appropriate option to the > kgi-target at opening time. Do you know how hard that "fall back feature" is to implement, when direct accel access is implemented? I barely made it for framebuffer+ioctl-only access. And it was ugly. Note that an application (which can have multiple threads) can get that switchaway signal _anywhere_ in its code. It might just be sending a complex sequence of accel commands. No logic can gracefully catch that from outside. >From inside, it is relatively easy. Thus I pledge for the following: 1. Signal the app for switchaway. 2. Let the app do whatever it thinks is reasonable to get ready for that to happen. Here the app can just ggiOpen a memvisual and the ggiCrossBlit to it, swap visuals and be happy. It can as well decide not to bother and stop itself or to disable output. 3. Signal the kernel that the switchaway can proceed. The nice point about that is, that you don't have to do all work in the signal handler, which is difficult, as you may want to wait for functions to complete etc. Moreover sending a signal doesn't block until the handler is complete or something, so we have to wait on some kind of callback anyway. The bad thing about it is, that the app may be broken and thus not go to step 3., or that the app is currently not interruptible (rewinding a tape e.g.). In that case KGI must have a fallback mechanism to keep the system responding. Best bet here is IMHO to SIGSTOP the application if it does not consent in time. Now what is "in time" ? IMHO this should be left to the user. He will know, why an app may currently be a bit slow to respond and might give it some extra time. Simplest thing would be to fall back to forced switch away when a second switchaway-request is issued by the user while the first one has not been acknowledged. CU, Andy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
