I have an ekoore perl tablet (wetab, exopc) with an egalax touchscreen. When I clic, hold and move then the cursor SOMETIMES jumps a fraction of second to an extreme of the screen (usually the left margin) which makes very difficult to select some text or to move a file to trash. Please note this is not the 'transformation matrix problem': https://bugs.freedesktop.org/show_bug.cgi?id=49347, my bug is different I use Archlinux with LXDE, easystroke 0.5.4 and 2.7.3 evdev driver built without mtdev. This problem is not present in the 2.7.3 arch repo version built with mtdev support, but unfortunately this driver has a lot of worst problems in my tablet, see https://bugs.archlinux.org/task/31350. I've downgraded evdev driver to 2.7.2, 2.7.1 and 2.7.0 from Arch ARM snapshots (all of them were built without mtdev), but the cursor jumping problem is present in all those no-mtdev drivers. I'm afraid I'm not an expert user, but please ask me for any information, log, video, test,... I can do to help to solve this issue. PD: sorry for my English mistakes, I'm Spanish
I can confirm this issue in evdev 2.7.2 & 2.7.3 built without mtdev support. The problem is most evident when selecting text or scrolling a window. The pointer randomly jumps to the top left corner before returning. When evdev is built with mtdev support, this issue is resolved, yet mtdev support causes other issues: https://bugs.archlinux.org/task/31350#comment98632
Sorry, the link should be https://bugs.freedesktop.org/show_bug.cgi?id=53669
An update; Previously I've tried with all the 2.7 versions (2.7.0, 2.7.1 and 2.7.2 from Arch Rollback Machine ARM; 2.7.3 built from Arch PKGBUILD removing the 'mtdev' dependence). The cursor jumped in all of them. Then I downgrade to 2.6.0 version (starting again from 2.7.3 Arch's PKGBUILD, I remove the 'mtdev' dependence and pointed to 2.6.0 source). Now the problem has gone, the cursor is stable and there are not any bugs. I don't know where the problem is, but it seems to be born between 2.6.0 and 2.7.0 versions
This bug is very apparent under VirtualBox: https://www.virtualbox.org/ticket/10853 From version 2.7.0 the pEvdev->vals valuator mask is reset immediately after posting the motion events: evdev.c [...] 1022 /* don't reset the touchMask */ 1023 } 1024 1025 if (pEvdev->vals) 1026 valuator_mask_zero(pEvdev->vals); 1027 pEvdev->num_queue = 0; 1028 pEvdev->abs_queued = 0; [...] After removing lines 1025-1026 the problem disappeared. It looks like a concurrency issue where Xorg only processes the event and reads the values after the reset, randomly and momentarily sending the mouse to (0, 0).
could this be https://bugzilla.redhat.com/show_bug.cgi?id=852841?
The symptoms are the same so it probably is. You seem to have fixed it on the xorg-server side though.
(In reply to comment #5) > could this be https://bugzilla.redhat.com/show_bug.cgi?id=852841? Honestly I'm not sure if it is the virtualbox problem. I don't use Virtualbox, I use a native Arch linux installation in a tablet (mine is an ekoore perl tablet, but it's the same hardware than wetab, exopc or mobi one tablets). Seems that many people suffer a jumping from (x,y) to (0,0) coordinates. I also suffer it, but it's noy very usual. What I usually suffer is a jumping to (0,y), sometimes to (x,0), sometimes to (1366,y) and sometimes to (x,768). That is, cursor usually jumps to the west, north, east or south, not to the northwest. I haven't read other people talking about east or south jumps, I recheck in my tablet to be sure I suffer jumping in all directions.
you can test if it is Bug 852481 by setting the matrix to something and back to the unity matrix xinput set-prop "device name" "Coordinate Transformation Matrix" 0.5 0 0 0 0.5 0 0 0 0 1 xinput set-prop "device name" "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 0 1 if this makes the issue disappear, this bug is a duplicate.
(In reply to comment #8) > you can test if it is Bug 852481 by setting the matrix to something and back > to the unity matrix Arch Linux x86_64, VirtualBox 4.2.0 guest xorg-server 1.12.4, xf86-input-evdev 2.7.3 The problem disappears after setting and resetting the matrix with: $ xinput set-prop "VirtualBox mouse integration" "Coordinate Transformation Matrix" 0.5 0 0 0 0.5 0 0 0 1.0 $ xinput set-prop "VirtualBox mouse integration" "Coordinate Transformation Matrix" 1.0 0 0 0 1.0 0 0 0 1.0 Simply resetting the matrix seems to suffice, producing only a small amount of initial (0, 0) readings.
I am in the same situation as David (OP) and have this issue using native Arch with my tablet device (no VM). The touchscreen in my device is reported as a usb tablet. Entering to tranformation matrix commands below resolved the issue for me. $ xinput set-prop <DEVICE> "Coordinate Transformation Matrix" 0.5 0 0 0 0.5 0 0 0 1 $ xinput set-prop <DEVICE> "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 1 So it would appear to be an issue with the initialisation of the transofmation matrix on X start. using evdev-2.7.3 built without MTDEV support as MTDEV support causes other touch event issues and breaks touch input coordinate rotation (see bug https://bugs.freedesktop.org/show_bug.cgi?id=53669) Cheers.
Closing as fixed, this does appear to be the same as the redhat bug posted above. Fixed in commmit 3d1051aecbb1955084804133cacd12c7f696833a From: Peter Hutterer <peter.hutterer@who-t.net> Date: Wed, 19 Sep 2012 19:56:39 +0000 Subject: dix: set the device transformation matrix
I've just rechecked and I were wrong, the cursor didn't jump to right or down, only to (0,0), (x,0) or (0,y) as the rest of users claimed. It was the known virtualbox problem, and the coordinate trick also works for me. Thanks for solving, Peter.
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.