-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adam Jackson wrote:
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
I'll add
5. Maximum number of open files hit (I experience when using KWin
compositing on intel driver).
I know of no non-C-A-Bs way to get out of it without rebooting.
<
https://bugzilla.redhat.com/show_bug.cgi?id=486695>
- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknSUpIACgkQiPi+MRHG3qTmdwCgqYkpYBmN+V8KG1BjWNoZO6Qd
6hcAoK7hLzmPqRTKg0xgPZ08SwkHaZDC
=m2fN
-----END PGP SIGNATURE-----