2009/3/31 Adam Jackson <ajax@xxxxxxxxxx>: > 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
