Created attachment 27601 [details] Xorg.0.log XWarpPointer + synaptics touchpad = extreme cursor jumping I have here a ThinkPad R61 7733A82 with a synaptics touchpad and a trackpoint. If I generate some pointer events (button presses or movements) with the touchpad and then do an XWarpPointer call, then the very next pointer event, regardless of source or type, causes the pointer to immediately slam into the extreme lower-right corner of the screen. However, if the last pointer event before the XWarpPointer came from the trackpoint, then I don't get the cursor jumping. The pointer operates normally otherwise, even after the abnormal jump. So, for example, if I move the cursor with the touchpad and then run a trivial program that does: XWarpPointer(display, None, None, 0, 0, 0, 0, 10, 10); Then pressing any mouse button or trying to move the cursor with either the trackpoint or the touchpad causes the undesirable cursor jump. However, if I move the cursor a bit with the trackpoint and then do the XWarpPointer, then I don't get the jumping. This bug is present regardless of which driver I use with the touchpad (synaptics or evdev). Both the synaptics and evdev drivers produce this behavior. I've done some playing with gdb, and here's a bit that looks interesting to me: Break in updateFromMaster, right before updateSlaveDeviceCoords. XWarpPointer is the only thing I've seen that satisfies this breakpoint condition. > (gdb) break getevents.c:641 if master == dev > (gdb) commands > >bt > >printf "Min/max/val: %d %d %d\n", master->valuator->axes->min_value, \ > master->valuator->axes->max_value, master->last.valuators[0] > >continue > >end > (gdb) break getevents.c:642 if master == dev > (gdb) commands > >printf "Min/max/val: %d %d %d\n", master->valuator->axes->min_value, \ > master->valuator->axes->max_value, master->last.valuators[0] > >continue > >end > (gdb) continue > > # Move cursor around with the touchpad, then do a XWarpPointer > [Switching to Thread 0x7f11e25d5700 (LWP 2912)] > Breakpoint 1, updateFromMaster (events=0x5367610, dev=0x51e7e20, type=4, > num_events=0x7fff8064f0e4) at getevents.c:641 > 641 CreateClassesChangedEvent(events, master, dev, type); > #0 updateFromMaster (events=0x5367610, dev=0x51e7e20, type=4, > num_events=0x7fff8064f0e4) at getevents.c:641 > #1 0x000000000044db1c in GetPointerEvents (events=0x5367610, pDev=0x51e7e20, > type=6, buttons=0, flags=20, first_valuator=0, num_valuators=2, > valuators=0x7fff8064f140) at getevents.c:1066 > #2 0x000000000045b809 in miPointerWarpCursor (pDev=0x51e7e20, > pScreen=0x245dfe0, x=427, y=579) at mipointer.c:580 > #3 0x00000000004875e0 in xf86WarpCursor (pDev=0x51e7e20, pScreen=0x245dfe0, > x=427, y=579) at xf86Cursor.c:473 > #4 0x000000000045b53c in miPointerSetCursorPosition (pDev=0x51e7e20, > pScreen=0x245dfe0, x=427, y=579, generateEvent=1) at mipointer.c:239 > #5 0x00000000005664ce in AnimCurSetCursorPosition (pDev=0x51e7e20, > pScreen=0x245dfe0, x=427, y=579, generateEvent=1) at animcur.c:277 > #6 0x000000000042b303 in ProcWarpPointer (client=<value optimized out>) > at events.c:3341 > #7 0x0000000000448fe4 in Dispatch () at dispatch.c:426 > #8 0x0000000000426995 in main (argc=10, argv=0x7fff8064f478, > envp=<value optimized out>) at main.c:283 > > Min/max/val: 1472 5472 417 > > Breakpoint 2, updateFromMaster (events=0x5367610, dev=0x51e7e20, > type=<value optimized out>, num_events=0x7fff8064f0e4) at getevents.c:643 > 643 master->last.slave = dev; > > Min/max/val: 1472 5472 2774 Move pointer with (say) the trackpoint, and *bam*, slammed into the corner. Notice that master->last.valuators[0] when from '417' to '2774' thanks to the updateSlaveDeviceCoords call. Now, move cursor around with the *trackpoint*, then do a XWarpPointer: > Breakpoint 1, updateFromMaster (events=0x5367610, dev=0x51e7e20, type=4, > num_events=0x7fff8064f0e4) at getevents.c:641 > 641 CreateClassesChangedEvent(events, master, dev, type); > #0 updateFromMaster (events=0x5367610, dev=0x51e7e20, type=4, > num_events=0x7fff8064f0e4) at getevents.c:641 > #1 0x000000000044db1c in GetPointerEvents (events=0x5367610, pDev=0x51e7e20, > type=6, buttons=0, flags=20, first_valuator=0, num_valuators=2, > valuators=0x7fff8064f140) at getevents.c:1066 > #2 0x000000000045b809 in miPointerWarpCursor (pDev=0x51e7e20, > pScreen=0x245dfe0, x=328, y=555) at mipointer.c:580 > #3 0x00000000004875e0 in xf86WarpCursor (pDev=0x51e7e20, pScreen=0x245dfe0, > x=328, y=555) at xf86Cursor.c:473 > #4 0x000000000045b53c in miPointerSetCursorPosition (pDev=0x51e7e20, > pScreen=0x245dfe0, x=328, y=555, generateEvent=1) at mipointer.c:239 > #5 0x00000000005664ce in AnimCurSetCursorPosition (pDev=0x51e7e20, > pScreen=0x245dfe0, x=328, y=555, generateEvent=1) at animcur.c:277 > #6 0x000000000042b303 in ProcWarpPointer (client=<value optimized out>) > at events.c:3341 > #7 0x0000000000448fe4 in Dispatch () at dispatch.c:426 > #8 0x0000000000426995 in main (argc=10, argv=0x7fff8064f478, > envp=<value optimized out>) at main.c:283 > > Min/max/val: -1 -1 318 > > Breakpoint 2, updateFromMaster (events=0x5367610, dev=0x51e7e20, > type=<value optimized out>, num_events=0x7fff8064f0e4) at getevents.c:643 > 643 master->last.slave = dev; > > Min/max/val: -1 -1 318 I note that in this case, the coordinate value is unchanged. Environment: Ubuntu 9.04 amd64 Kernel: 2.6.31-rc2-00079-gdc53fff xserver, Xlib, xf86-input-evdev, and just about everything else xorg-related: current git Xorg.0.log attached. HTH!
Aagh, what a messy report! Sorry about that, seems I was in too much of a rush to submit it! Anyway, thought I should mention two other things: - This bug is a regression, introduced sometime in the last few months. (I've been running beta version of this stuff for a while now.) I haven't bisected this yet, but I can if that would help. - Some time a few weeks ago, this jumping problem briefly got a little more severe. If I made movements/button presses from the trackpoint, then doing anything with the touchpad also caused a jump to the lower-right corner. It has been fixed since, but maybe that's just an accident, and I suppose it could be related to this bug. I can also investigate that brief regression if that would help. Hope this helps!
This problem seems to have disappeared in current git. Hopefully it'll stay that way ...
commit c806162c133603a99d9cd844bb04485bb663707d should have been it.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.