Just a random comment: IIRC in the early days of kgi (aka scrdrv), we had another idea on how to deal with the switch-away business:
1. If switchaway occurs, ask the Application to switch away gracefully (using a signal). 2. If the application consents using a callback, all is well. The application has thus the opportunity to handle the case nicely. 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. 3. If the app does not consent, it can be switched away forcefully by just requesting the switch again. It will then just be sigstopped. I think such a scheme is worth considering, as I am not sure, if it is always possible to _gracefully_ switch away and back when usermode accesses the regs of the hardware. It would be nice to have a "best effort" way to handle this case. I.e. "nice" applications would work fine, even if the HW is problematic to save and restore, while we can still forcefully switch away broken applications, eventually having to cope with wrong drawings or similar after restore. Regarding saving the FB: This can be done without application help (there was a daemon for this in some early versions of scrdrv), but I think when it comes to HW-Register access, that won't quite help. CU, ANdy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
