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 _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel