F11: xorg decision to disable Ctrl-Alt-Backspace

[Colin Walters]

2009/3/31 Adam Jackson <ajax at redhat.com>:
> On Mon, 2009-03-30 at 22:42 +0200, Kevin Kofler wrote:
>> Colin Walters wrote:
>> > No, the right solution is to examine the cases for why people were
>> > using the key before, and come up with a design which addresses them.
>>
>> This will not help at all, because people expect to be able to use the
>> current key combo, not something new they never heard of.
>
> So let's list the cases that zap would actually recover from:
>
> 1: stuck grabs
> 2: focus reverts to None and your window manager is dead
> 3: X driver that's decided to stop rendering (or stop rendering
> correctly)

Let me add:

4: Randr configuration is either broken or out of date, and the system
didn't detect it correctly

More than a few times now I've forgotten I had set up an external
monitor, suspended, and unsuspended later and faced with a black
screen thought my machine had locked.  Of course this is a system bug,
but then all of these things are.

> For case 1, you might be able to recover if you could just figure out
> which client was being obstreperous.  So clearly the right thing is to
> dump active grab state to the X log on VT switch.  If there's anything
> there, then you know who to blame and you can pkill just that and
> recover.  If there's not, then the session is doomed.

That's useful.  A lot of the time I have a good idea of what app has a
stuck grab, but this is a bit easier.  Ideally there would be a way to
forcibly ungrab but I suppose that may confuse application toolkits.

Anyways one could obviously spend almost arbitrary amounts of time
writing recovery code, but I just wanted the discussion to at least
consider writing *some* new code and looking at the cases, rather than
having "enable or don't enable DontZap" be the only options.