It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
dylanmccall at gmail.com
Mon May 25 18:21:27 PDT 2009
> I wouldn't disagree that there is a problem for novice programmers,
> debugging a GUI app for the first time. But for these people, an obscure
> way to reconfigure their X server doesn't help much either.
> - Owen
I think that debugging example is a fine example, but only a subset of
the trouble today's state of mouse grabs creates. (And I get the sense
David is bothered by this issue in a wider sense). The result is that a
single clueless process (ANY process) can cause a user's system to "lock
up" in a completely perplexing manner. Try troubleshooting one of these
issues over the phone. ("Which program were you last using?... okay...
err, type ps -A...").
I will add whoever solves this problem to my list of personal heroes,
right up there beside Stephen Hawking. If it turns out to be a lot of
people... well, I guess I'll owe a lot of beer.
I think there are many people who think of this the same way.
I'm sure there are many things that could be done to not have your
session eaten by a hanging mouse grab if you know it will happen in
advance, but the fact is something here is very, very wrong and a
band-aid doesn't cut it. It's either the boatload of GUI toolkits that
use mouse grabs, or the system that provides the function in the first
Just out of curiosity, is there something xinput 2 is doing to resolve
this? (I at least get the feeling that one could rescue an inoperable
pointer by plugging in a second mouse with an MPX-crazed distribution.
Slightly easier to troubleshoot, maybe).
On a lighter note: Thanks for the debugging tips, Owen :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the xorg