<div style="direction: ltr;">Hi everyone, I need some help with an unusual requirement... I'm working on a project that runs on an x86 Linux (2.6.9) machine with several X (6.8.1) applications (some using graphics acceleration/3D conceivably). I need the following functionality: When an external event arrives (such as a critical error) I'd like to be able to quickly display a screen that would cover any other windows in existence. This should happen in a half a second or so, even when the PC is heavily loaded. Unfortunately when some (even low priority) application causes memory swapping by allocating/freeing a large block, any (even RT priority) application is blocked from memory allocation until the first allocation is sorted out. When switching applications, the X server (and probably the X lib too) tries to do memory allocation, and thus displaying the screen slows to a crawl. So the obvious solution (running a full screen X client that displays the desired screens, putting it in the background; then bringing it on top when needed) is not working. Sometimes bringing the window forward and redrawing it takes several (tens of) seconds. Here are some of the options I considered. Please comment on which one looks feasible (or whether there is a simpler way). As you will see, I'm willing to consider hacking X, or anything else to get what I want :) However, it would be cool if I could leave the X server alone. 1. Displaying a transparent window over any window, and drawing to it at the critical moment -> if X slows down, I have a feeling this drawing will slow down too, unless I put some hack in X that treats this overlay in a special way somehow. I'm also not sure if X has facilities for such a transparent window. 2. Switching to another VT, then displaying the emergency screen by writing to the frame buffer -> this re-initalizes the VGA board, leading to the screen going blank (for quite a long time on some monitors) 3. Wrestling ownership of the display board from X through DRM -> due to the extremely sparse documentation, I'm not sure how X (and the video board) would behave if it was in the middle of something (such as rendering a 3D scene). Or whether DRM will even allow me to get control when X is busy using the board. 4. Doing an "mlockall" on X so it always has readily available memory -> this may lead to some nasty memory management issues if I allocate a ton of physical RAM for X (or if I don't pre-allocate enough pages, it can again get unresponsive). In addition, I'm worried that the interaction between X and a foreground applications that is busy trashing can slow down X nonetheless. 5. Inserting a short-circuit in X that allows a client to immediately draw the entire screen through DRI (or some similar method) -- I'm not sure how complex is it to trigger a context switch and let the application draw through it. 6. Buying a video board that is able to do hardware overlays or can handle multiple screen buffers. My emergency app would flip the switch in the video card to display the appropriate overlay/screen buffer -- are there any such beasts out there that don't break the bank? Please comment! Thanks a lot in advance, </div> Tamas