F11: xorg decision to disable Ctrl-Alt-Backspace
Colin Walters
walters at verbum.org
Tue Mar 31 14:51:52 UTC 2009
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.
More information about the devel
mailing list