Problem with mouse input "freeze"

[Oldřich Jedlička]

Hi Peter,

On Tuesday 12 of January 2010 at 03:12:15, Peter Hutterer wrote:
> On Fri, Jan 08, 2010 at 09:08:52PM +0100, Oldřich Jedlička wrote:
> > Dne Pá 8. ledna 2010 07:04:34 Peter Hutterer napsal(a):
> > > On Thu, Jan 07, 2010 at 10:13:24PM +0100, Oldřich Jedlička wrote:
> > > > > > can I assume you only have one master device and you aren't
> > > > > > playing around with MPX? what's the output of xinput --list
> > > > > > --short? is the pad a floating slave?
> > > > > > 
> > > > > > I can't reproduce it here, neither on 1.7 nor on master so I
> > > > > > might need some special setup.
> > > > > 
> > > > > I will add some logging to valuators update function (the code
> > > > > touched in your latest patch and updateStaveDeviceCoords) in the
> > > > > evening, just to be sure that the valuators are updated and kept
> > > > > correctly. If you point me to some other place in code, I can add
> > > > > logging there too.
> > > > 
> > > > I've tried KDE4 just to be sure and it works correctly there. The
> > > > KDE3.5 is affected by this bug. So I don't know if it makes sense to
> > > > investigate it further (if it is bug in KDE3.5/Qt or xorg).
> > > 
> > > weird. the only client thing that should trigger this behaviour is a
> > > direct XI2 slave grab. KDE 3.5 can't do that though, it came out way
> > > before XI2.
> > > 
> > > I might have to dig out a kde installation to reproduce that.
> > > If you can ssh in during that time, please run xinput --list --short
> > > when this happens and see if the device got detached.
> > 
> > Hi Peter,
> > 
> > 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?

Cheers,
Oldřich.

> 
> Cheers,
>   Peter
> _______________________________________________
> xorg-devel mailing list
> xorg-devel at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel