Fwd: Is disabling ctrl-alt-backspace really such a good idea?

[John Moser]

On Tue, Feb 10, 2009 at 8:57 PM, Mackenzie Morgan <macoafi at gmail.com> wrote:
> On Tue, 2009-02-10 at 19:06 -0500, John Moser wrote:
>> On Tue, Feb 10, 2009 at 10:57 AM, Justin M. Wray
>> <wray.justin.ubuntu at gmail.com> wrote:
>> > Even if a new user is unfamiliar with the key combination, it only takes a little education OR them doing it once. Lessons are learned hard.
>> >
>>
> Not dead-simple...in fact: impossible!  The point of C-A-B is when X has
> crashed or locked.  It by definition cannot do what you are suggesting
> in such a situation.

By definition, if X is completely incapable of executing any
additional codepath, it is itself completely incapable of terminating
when C-A-B is pressed.  C-A-B doesn't work when X fails to actually
obtain and respond to user input; it does work when X fails to pass
user input along to X clients, fails to update the display, fails to
respond to X clients, etc.  If the entire X process enters a state
from which it cannot continue execution, C-A-B does not work at all;
it's not a kernel function.

The solution I described was one which will fail to properly execute
when X cannot present clients to the user or properly deliver input to
the user, i.e. when it's lost control of the display, driver, etc.  If
X can still handle a zap, however, then it can also spawn a child
process and react to that child process' failure to properly execute
(i.e. notification by return code).

One other note is you really need to release the mouse from whoever
has it if you implement this.  I've had qemu crash, holding the mouse,
and now I no longer have mouse/keyboard in X aside from the ability to
ctrl-alt-F1 and execute another qemu to grab/release the mouse with.
Also nice would be a button that says "Task Manager" and brings up a
task manager, in display-frozen view, so that misbehaving mouse
grabbers can't have the mouse back until you kill them.