$ xinput --version xinput version 1.6.0 XI version on server: 2.2 $ pacman -Q xorg-server xorg-server 1.13.0-2 $ uname -a Linux timothy 3.5.6-1-ARCH #1 SMP PREEMPT Sun Oct 7 19:30:49 CEST 2012 x86_64 GNU/Linux I am not sure, but I have been told that my issue may be related to this: http://patchwork.freedesktop.org/patch/5024/ I have three pointer devices: ------------------------ $ xinput --list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ QUANTA OpticalTouchScreen id=9 [slave pointer (2)] ⎜ ↳ TPPS/2 IBM TrackPoint id=11 [slave pointer (2)] ⎜ ↳ Serial Wacom Tablet WACf004 stylus id=13 [slave pointer (2)] ⎜ ↳ Serial Wacom Tablet WACf004 eraser id=14 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Sleep Button id=8 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)] ↳ ThinkPad Extra Buttons id=12 [slave keyboard (3)] ------------------------- One is a trackpoint on my Lenovo X61T tablet computer. One is a stylus on the same computer. And a third is the touch screen on an external monitor plugged in through USB: $ lsusb .... Bus 003 Device 004: ID 0408:3001 Quanta Computer, Inc. Optical Touch Screen .... When I plug in my external monitor and start x all three input devices work without trouble. When I run: xrandr --output VGA1 --auto --right-of LVDS1 Of course, the stylus and the touch display start working for the entirety of the screen. When I run: xinput --map-to-output 13 LVDS1 xinput --map-to-output 14 LVDS1 To map my stylus to the My stylus begins to work as expected, mapping to the correct coordinates on the screen. When I run: xinput --map-to-output 9 VGA1 My finger location is tracked properly when I hover my finger over the screen. However when I pres my finger down, the click registers and then the cursor jumps to the right. The size of the jump is proportional to the leftness of the touch. If I touch at the right edge then there is no jump. If I touch at the left edge the jump is large(several inches). If I restart the process and instead use (--left-of): xrandr --output VGA1 --auto --left-of LVDS1 then the cursor jumps to the left after the touch. This is clearly a high level bug. As I said, there is no problem when the displays are left in their mirrored state. Thank you for your time in considering this problem, and I look forward to a fix, and in the mean time, any pointers as how I might get around this problem. Timothy
This is not an xinput app bug, but we seem to be missing a Server/Input/Xinput component... I'll need to clean that up later...
please record the device and the touch events (when it jumps) with evemu and attach both files here. http://people.freedesktop.org/~whot/evemu/
Created attachment 68791 [details] Devices file
Created attachment 68792 [details] device descriptoin file
Created attachment 68793 [details] Events file
Comment on attachment 68793 [details] Events file At the beginning of the recording I am pressing on the screen with my finger. Near the end you can see me moving my finger above the screen without pressing down.
I can confirm that I am seeing the same behavior with my Acer T232HL as VGA1. Obviously this makes the touchscreen quite useless in a xinerama style layout atm although everything works fine if I clone the primary display or turn off the first display and just use the touchscreen monitor on the second display. If you need any test info from me as well, I would be willing to submit it as well.
(In reply to comment #7) > I can confirm that I am seeing the same behavior with my Acer T232HL as > VGA1. Obviously this makes the touchscreen quite useless in a xinerama > style layout atm although everything works fine if I clone the primary > display or turn off the first display and just use the touchscreen monitor > on the second display. If you need any test info from me as well, I would > be willing to submit it as well. tested with xorg server 1.13.1 and xinput 1.6.0 and verified this is still a bug.
I played those events but given that I don't have a device, I don't see the effect. Remember, if I emulate this device all I see is the cursor move around. What I need from you is a recording that is limited to a single touch that shows the effect, plus a detailed explanation of what you expect to happen and when. the recording you provided contains over 2800 single events, it's hard to tell what "near the end" means.
Created attachment 72421 [details] device.txt Acer T232HL Touchscreen monitor event device
Created attachment 72422 [details] events.txt After calling xinput --map-to-output 12 VGA1 and ran evemu-record, I touched the screen in one place on the left side of the screen and let go. When I let go, the cursor jumped to the right. You'll see this in the playback.
Created attachment 72433 [details] A single touch Here I have recorded just one touch event, and you can see how I recorded it in this video: http://youtu.be/os4RmPYPyMo I start the recording on my laptop screen, and then I move the mouse using the thinkpad nub to the large touch monitor and then I touch once on the xournal canvas, you can clearly see that the touch event registered in the right place as a large grey circle appears directly beneath the white pencil shaped pointer and then you can see that the cursor jumps after registering the touch event, such that the cursor(the black square) ends up far to the right of the actual touch event. Hope this clears things up at least a little...
Created attachment 72434 [details] The device file for that single touch...
Thanks for the video and the new file, I did manage to reproduce this on the 1.13 branch. This bug is a dupe of Bug 49347, fixed upstream with commit 3b9f1c701787965246638c1a6fd99fb2b6078114. I'll backport that to the 1.13 branch once I find the time for it. *** This bug has been marked as a duplicate of bug 49347 ***
Thanks! :)
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.