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) In case 3, you need to blow away the session and there's no getting around it. So VT switch and killall gnome-session will do just fine. For case 2, I seem to recall this being an unpleasant requirement of the X protocol somewhere along the line; but I'm looking into it. 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. Something like this perhaps: http://ajax.fedorapeople.org/patches/xserver-grab-debugging.patch I mean, I know it's bad form to post code to a development list, but I hope I can be forgiven this time. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list