Problem with mouse input "freeze"
Hi list and Peter, this is a continuation from linuxwacom-devel mailing list - the full thread (few messages actually) can be found here http://sourceforge.net/mailarchive/message.php?msg_name=201001022352.48459.oldium.pro%40seznam.cz So let's start from the beginning. I had a problem: when I pressed a key on keyboard, then a PAD button on tablet that emitted a key and then a normal PAD button on the tablet, the mouse moved to [0,0] and mouse input "freezed". The "freeze" means that mouse (tablet/ordinary mouse) moves, but there are no hover effects, no menu selection, no clicks accepted by applications - until some key is pressed. The move to [0,0] has been fixed by the patch from Peter Hutterer from this mailing list - patch with subject: [PATCH v2] dix: don't update the slave coordinates from the VCK. The mouse input "freeze" problem is still there, the steps to reproduce have changed: I have to press a key on keyboard, then double-click button 2 on tablet (no movement events in between - reproduced both with tablet PAD key and with tablet pen). What happens is that with only the single-click the local menu opens (but everything works); with double-click the menu opens, but doesn't go away as usual - the mouse input "freezes" instead (as described above). My guess is that there are still some valuators problems, so that the application grabs the mouse input and doesn't know what to do next. Thanks for any help. Regards, Oldřich. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input "freeze"
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@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input "freeze"
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
Re: Problem with mouse input "freeze"
On Wed, Jan 06, 2010 at 09:00:55PM +0100, Oldřich Jedlička wrote: > Hi list and Peter, > > this is a continuation from linuxwacom-devel mailing list - the full thread > (few messages actually) can be found here > > > http://sourceforge.net/mailarchive/message.php?msg_name=201001022352.48459.oldium.pro%40seznam.cz > > So let's start from the beginning. I had a problem: when I pressed a key on > keyboard, then a PAD button on tablet that emitted a key and then a normal > PAD > button on the tablet, the mouse moved to [0,0] and mouse input "freezed". The > "freeze" means that mouse (tablet/ordinary mouse) moves, but there are no > hover effects, no menu selection, no clicks accepted by applications - until > some key is pressed. > > The move to [0,0] has been fixed by the patch from Peter Hutterer from this > mailing list - patch with subject: > > [PATCH v2] dix: don't update the slave coordinates from the VCK. > > The mouse input "freeze" problem is still there, the steps to reproduce have > changed: I have to press a key on keyboard, then double-click button 2 on > tablet (no movement events in between - reproduced both with tablet PAD key > and with tablet pen). What happens is that with only the single-click the > local menu opens (but everything works); with double-click the menu opens, > but > doesn't go away as usual - the mouse input "freezes" instead (as described > above). > > My guess is that there are still some valuators problems, so that the > application grabs the mouse input and doesn't know what to do next. 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. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input "freeze"
Hi Peter, Dne čtvrtek 07 Leden 2010 07:09:21 Peter Hutterer napsal(a): > On Wed, Jan 06, 2010 at 09:00:55PM +0100, Oldřich Jedlička wrote: > > Hi list and Peter, > > > > this is a continuation from linuxwacom-devel mailing list - the full > > thread (few messages actually) can be found here > > > > > > http://sourceforge.net/mailarchive/message.php?msg_name=201001022352.4845 > >9.oldium.pro%40seznam.cz > > > > So let's start from the beginning. I had a problem: when I pressed a key > > on keyboard, then a PAD button on tablet that emitted a key and then a > > normal PAD button on the tablet, the mouse moved to [0,0] and mouse input > > "freezed". The "freeze" means that mouse (tablet/ordinary mouse) moves, > > but there are no hover effects, no menu selection, no clicks accepted by > > applications - until some key is pressed. > > > > The move to [0,0] has been fixed by the patch from Peter Hutterer from > > this mailing list - patch with subject: > > > > [PATCH v2] dix: don't update the slave coordinates from the VCK. > > > > The mouse input "freeze" problem is still there, the steps to reproduce > > have changed: I have to press a key on keyboard, then double-click button > > 2 on tablet (no movement events in between - reproduced both with tablet > > PAD key and with tablet pen). What happens is that with only the > > single-click the local menu opens (but everything works); with > > double-click the menu opens, but doesn't go away as usual - the mouse > > input "freezes" instead (as described above). > > > > My guess is that there are still some valuators problems, so that the > > application grabs the mouse input and doesn't know what to do next. > > 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 don't have anything special (I hope), the xorg-server is installed from Gentoo package, version 1.7.3.902. It contains patch from bug 25400 (added by Gentoo) and the one I've mentioned above. Output from `xinput --list --short` is attached. I've added also my xorg.conf and Xorg.0.log. > > Cheers, > Peter > ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS GlidePoint id=8[slave pointer (2)] ⎜ ↳ PS/2 Mouseid=9[slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 eraser id=10 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 cursor id=11 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 pad id=12 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 id=13 [slave pointer (2)] ⎜ ↳ Logitech USB RECEIVER id=14 [slave pointer (2)] ⎜ ↳ Logitech USB Receiver id=15 [slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=6[slave keyboard (3)] ↳ i2c IR (AVerMedia Cardbus remot id=7[slave keyboard (3)] ↳ Logitech USB Receiver id=16 [slave keyboard (3)] ↳ Acer Crystal Eye webcam id=17 [slave keyboard (3)] ↳ Sleep Button id=18 [slave keyboard (3)] ↳ Video Bus id=19 [slave keyboard (3)] ↳ Power Button id=20 [slave keyboard (3)] This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.7.3.902 (1.7.4 RC 2) Release Date: 2009-12-26 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-drm i686 Current Operating System: Linux oldium 2.6.32-drm #5 SMP PREEMPT Mon Jan 4 00:20:21 CET 2010 i686 Kernel command line: root=/dev/sda3 gentoo=nodevfs atkbd.softraw=1 elevator=cfq lapic pci=assign-busses video=radeonfb:1024x...@75 radeon.modeset=1 Build Date: 05 January 2010 08:37:13AM Current version of pixman: 0.17.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 7 08:24:18 2010 (==)
Re: Problem with mouse input "freeze"
Hi Peter, Dne čtvrtek 07 Leden 2010 07:09:21 Peter Hutterer napsal(a): > On Wed, Jan 06, 2010 at 09:00:55PM +0100, Oldřich Jedlička wrote: > > Hi list and Peter, > > > > this is a continuation from linuxwacom-devel mailing list - the full > > thread (few messages actually) can be found here > > > > > > http://sourceforge.net/mailarchive/message.php?msg_name=201001022352.4845 > >9.oldium.pro%40seznam.cz > > > > So let's start from the beginning. I had a problem: when I pressed a key > > on keyboard, then a PAD button on tablet that emitted a key and then a > > normal PAD button on the tablet, the mouse moved to [0,0] and mouse input > > "freezed". The "freeze" means that mouse (tablet/ordinary mouse) moves, > > but there are no hover effects, no menu selection, no clicks accepted by > > applications - until some key is pressed. > > > > The move to [0,0] has been fixed by the patch from Peter Hutterer from > > this mailing list - patch with subject: > > > > [PATCH v2] dix: don't update the slave coordinates from the VCK. > > > > The mouse input "freeze" problem is still there, the steps to reproduce > > have changed: I have to press a key on keyboard, then double-click button > > 2 on tablet (no movement events in between - reproduced both with tablet > > PAD key and with tablet pen). What happens is that with only the > > single-click the local menu opens (but everything works); with > > double-click the menu opens, but doesn't go away as usual - the mouse > > input "freezes" instead (as described above). > > > > My guess is that there are still some valuators problems, so that the > > application grabs the mouse input and doesn't know what to do next. > > 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. Cheers, Oldřich. > > Cheers, > Peter > ___ > xorg-devel mailing list > xorg-devel@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-devel > ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input "freeze"
Hi Peter, Dne čtvrtek 07 Leden 2010 09:18:05 Oldřich Jedlička napsal(a): > Hi Peter, > > Dne čtvrtek 07 Leden 2010 07:09:21 Peter Hutterer napsal(a): > > On Wed, Jan 06, 2010 at 09:00:55PM +0100, Oldřich Jedlička wrote: > > > Hi list and Peter, > > > > > > this is a continuation from linuxwacom-devel mailing list - the full > > > thread (few messages actually) can be found here > > > > > > > > > http://sourceforge.net/mailarchive/message.php?msg_name=201001022352.48 > > >45 9.oldium.pro%40seznam.cz > > > > > > So let's start from the beginning. I had a problem: when I pressed a > > > key on keyboard, then a PAD button on tablet that emitted a key and > > > then a normal PAD button on the tablet, the mouse moved to [0,0] and > > > mouse input "freezed". The "freeze" means that mouse (tablet/ordinary > > > mouse) moves, but there are no hover effects, no menu selection, no > > > clicks accepted by applications - until some key is pressed. > > > > > > The move to [0,0] has been fixed by the patch from Peter Hutterer from > > > this mailing list - patch with subject: > > > > > > [PATCH v2] dix: don't update the slave coordinates from the VCK. > > > > > > The mouse input "freeze" problem is still there, the steps to reproduce > > > have changed: I have to press a key on keyboard, then double-click > > > button 2 on tablet (no movement events in between - reproduced both > > > with tablet PAD key and with tablet pen). What happens is that with > > > only the single-click the local menu opens (but everything works); with > > > double-click the menu opens, but doesn't go away as usual - the mouse > > > input "freezes" instead (as described above). > > > > > > My guess is that there are still some valuators problems, so that the > > > application grabs the mouse input and doesn't know what to do next. > > > > 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). Cheers, Oldřich. > Cheers, > Oldřich. > > > Cheers, > > Peter > > ___ > > xorg-devel mailing list > > xorg-devel@lists.x.org > > http://lists.x.org/mailman/listinfo/xorg-devel > > ___ > xorg-devel mailing list > xorg-devel@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-devel > ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input "freeze"
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. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input "freeze"
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 :-) Cheers, Oldřich. > Cheers, > Peter > ___ > xorg-devel mailing list > xorg-devel@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-devel > ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS GlidePoint id=8[slave pointer (2)] ⎜ ↳ PS/2 Mouseid=9[slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 eraser id=10 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 cursor id=11 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 pad id=12 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 id=13 [slave pointer (2)] ⎜ ↳ Logitech USB RECEIVER id=14 [slave pointer (2)] ⎜ ↳ Logitech USB Receiver id=15 [slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=6[slave keyboard (3)] ↳ i2c IR (AVerMedia Cardbus remot id=7[slave keyboard (3)] ↳ Logitech USB Receiver id=16 [slave keyboard (3)] ↳ Acer Crystal Eye webcam id=17 [slave keyboard (3)] ↳ Sleep Button id=18 [slave keyboard (3)] ↳ Video Bus id=19 [slave keyboard (3)] ↳ Power Button id=20 [slave keyboard (3)] ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input "freeze"
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. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
