Problem with mouse input "freeze"

[Peter Hutterer]

On Wed, Feb 03, 2010 at 07:24:59PM +0100, Oldřich Jedlička wrote:
> > > the `xinput --list --short` is exactly the same as without the problem -
> > > attached (is it the right command?). I'm able to ssh onto the machine, so
> > > if I should do something special with gdb, I can. Just point me into the
> > > right direction :-)
> > 
> > thanks. xinput output doesn't show anything special so jury is still out on
> > the problem. The interesting parts to look at with gdb are:
> > Is GetPointerEvents being called for the device? If not, it's a driver
> > issue.
> > what's the value of dev->public.processInputEvent? If it's EnqueueEvent,
> > the device is frozen by some client, you need to try to identify that
> > client. Is dev->u.master still set or NULL? if the latter, it's
> > temporarily detached from a grab and doesn't send core events.
> > 
> > Those are the first three I'd look at to get a clue of what the issue might
> > be. If the device isn't frozen, step through ProcessOtherEvents and see
> > where and why the events disappear.
> 
> I've finally got to the problem analysis. The Wacom input device isn't frozen, 
> but the master device is.
> 
> I've checked the input processing and in mieqProcessDeviceEvent the dev("Wacom 
> Intuos3 6x8")->public.processInputProc is ProcessKeyboardEvent and the 
> master("Virtual core pointer")->public.processInputProc is EnqueueEvent (which 
> gets called at the end of mieqProcessDeviceEvent). Is this normal?

it the master pointer has a frozen grab, that's usually a sign of a client
not releasing the grab. The VCP's processInputProc is changed to
EnqueueEvent in response to grab with GrabModeSync on the pointer.

the trick is finding the client that does it and then finding out what
triggers the bug. The best way to narrow down the client is to ssh in and
kill clients off one-by-one until the pointer is released.
Once you've found which client it was, try to reproduce and verify. Once
that's verified, you can go towards reproducing the steps that make the
pointer freeze.

given that your original scenario included a button configured as a key I
guess that key would trigger some specific function, so it's likely that
some client has a grab on that key. Kill off that client first and see if
that helps.

Next - use xmond or xscope to check if the event is delivered to that client
properly. Could be that the server is doing something wrong. Best way to do
that is have a server that works and compare the event flow from a test
case.

also try this patch from the list (or bugzilla), it's possible that this is
the cause:
dix: if owner-events is true for passive grabs, add the window mask (#25400)

That's all I can recommend for now. Bugs like this are tricky to track down,
the priority is always on getting a simple test case.


Cheers,
  Peter