|Summary:||xf86-input-evdev-2.7.3 multiple issues|
|Component:||Input/evdev||Assignee:||Peter Hutterer <peter.hutterer>|
|Status:||RESOLVED WONTFIX||QA Contact:||Xorg Project Team <xorg-team>|
|Priority:||medium||CC:||andyrtr, padfoot, peter.hutterer, thomas.luebking|
|i915 platform:||i915 features:|
Description Padfoot 2012-08-18 08:05:49 UTC
With the update from 2.7.2 to 2.7.3, multiple issues have begun occuring on my system. 1. Rotate screen using xrandr (works) and adjust input co-ordinates using xinput set-prop on 'Evdev Axes Swap' and 'Evdev Axis Inversion' properties (appears to work as xinput list-props reports the change) yet the input co-ordinates are not modified at all. 2. Gtk3 menu bar buttons: To activate the menu, I have to click on the menu button, it is just highlighted, click away from it and then click it again, then the menu appears. 3. Using an on-screen keyboard when multiple windows are open, input focus is randomly stolen between open windows as I type on the keyboard. I have to close all but one window to be able to use the on-screen keyboard. Using Arch Linux 64 bit kernel version 3.4.7 on an Acer Iconia Tab with eGalax touch screen. Reverting to xf86-input-evdev-2.7.2 resolves all issues. Cheers.
Comment 1 Padfoot 2012-08-18 08:12:55 UTC
Oh, an additional issue I just remembered: Using easystroke for gesture input allows you to assign gestures to keystrokes, scripts and scroll input. Scroll input no longer works with 2.7.3. Functionality returns on downgrade to 2.7.2. Cheers.
Comment 2 Peter Hutterer 2012-08-20 01:33:53 UTC
In the future, please file separate bugs for separate issues. Did you update evdev only or other components as well? does Arch carry any patches? In regards to your issues: 2. this is unlikely a evdev issue, evdev merely sends button events, it doesn't know where you clicked. 3. is not an evdev issue, evdev doesn't handle focus. easystroke: again, this isn't something evdev handles, so I don't see how the downgrade can fix it. looking at the diff between 2.7.2 and 2.7.3 I can't see a patch that could trigger these issues, unless you're using the ButtonMapping option (which was broken in 2.7.2) or you're getting read errors. anything in the log? please attach your log file anyway.
Comment 3 Padfoot 2012-08-20 06:55:36 UTC
I have xorg-server/-common/-xephyr/-devel packages held at 1.12.3 as the current version in the Arch repos (126.96.36.1991) kills my multitouch driver (using the egalax binary blob multitouch driver from http://home.eeti.com.tw/web20/eGalaxTouchDriver/linuxDriver.htm). This happened last time there was a .9xx version, but was fixed on the next version, so I expect 1.12.4 to work with the multitouch driver. Someone in the Arch forums suggested it could be to do with MTDEV support in this version of evdev. Could that be conflicting with the binary multitouch driver do you think? The Arch evdev package is vanilla. No patches applied. A correction on my kernel version. It is 3.4.4 (using arch package patched to support my accelerometer). Regards issues 2, 3 and easystroke, I understand that they aren't linked directly with evdev, yet the only resolution to the issue is by downgrading evdev. I even experience these isues with kernel 3.4.9 and all xorg pavkages up to date (of course I no longer have multitouch doing this) Bear with me while I upgrade the packages again to get a log for you (I only have the log for the downgraded version - just noticed this is being spammed with [ 1852.230] (II) RADEON(0): EDID vendor "AUO", prod id 21460 [ 1852.230] (II) RADEON(0): Printing DDC gathered Modelines: [ 1852.230] (II) RADEON(0): Modeline "1280x800"x0.0 71.20 1280 1288 1298 1464 800 803 804 808 -hsync -vsync (48.6 kHz eP) [ 1852.480] (II) RADEON(0): EDID vendor "AUO", prod id 21460 [ 1852.481] (II) RADEON(0): Printing DDC gathered Modelines: [ 1852.481] (II) RADEON(0): Modeline "1280x800"x0.0 71.20 1280 1288 1298 1464 800 803 804 808 -hsync -vsync (48.6 kHz eP) [ 1852.737] (II) RADEON(0): EDID vendor "AUO", prod id 21460 [ 1852.737] (II) RADEON(0): Printing DDC gathered Modelines: [ 1852.737] (II) RADEON(0): Modeline "1280x800"x0.0 71.20 1280 1288 1298 1464 800 803 804 808 -hsync -vsync (48.6 kHz eP) [ 1852.982] (II) RADEON(0): EDID vendor "AUO", prod id 21460 [ 1852.982] (II) RADEON(0): Printing DDC gathered Modelines: [ 1852.982] (II) RADEON(0): Modeline "1280x800"x0.0 71.20 1280 1288 1298 1464 800 803 804 808 -hsync -vsync (48.6 kHz eP) [ 1853.231] (II) RADEON(0): EDID vendor "AUO", prod id 21460 [ 1853.231] (II) RADEON(0): Printing DDC gathered Modelines: [ 1853.231] (II) RADEON(0): Modeline "1280x800"x0.0 71.20 1280 1288 1298 1464 800 803 804 808 -hsync -vsync (48.6 kHz eP) Regards button mapping, I am using xorg auto generated config, so none of that is set. Regards issue 1, I gather that is being investigated? Cheers
Comment 4 Padfoot 2012-08-20 07:43:13 UTC
xorg-server-188.8.131.521, xorg-server-devel-184.108.40.2061, xorg-server-xephyr-220.127.116.111, xorg-server-common-18.104.22.1681, xf86-input-evdev-2.7.3 and kernel-3.4.9 All issues persist except for focus stealing. Xorg.0.log - http://pastebin.com/Pbj4p5Ft And of course, no multitouch as binary driver does not work with .901 versions (should be good with 1.12.4 though) Cheers.
Comment 5 Padfoot 2012-08-20 09:00:23 UTC
My guess for 2, 3 and easystroke, is possibly an incorrect event (or no event in the case of scroll) is being generated on touch input. Cheers.
Comment 6 Peter Hutterer 2012-08-21 08:23:20 UTC
Please don't send logs to pastebin, just attach them here. Pastebin logs go away (like this one did) and are not preserved for posterity. You're running a binary driver? do you see the issues without it too?
Comment 7 Padfoot 2012-08-22 06:50:50 UTC
I will have to get another log for you, but there does not appear to be anything useful regarding these issues there. The issues remain both with and without the binary driver, and regardless of the other xorg components being upgraded or not. The only resolution I have found is downgrading evdev.
Comment 8 Padfoot 2012-08-22 07:35:54 UTC
Created attachment 65936 [details] Xorg.0.log without binary driver
Comment 9 Padfoot 2012-08-22 07:37:38 UTC
Created attachment 65937 [details] Xorg.0.log with binary driver
Comment 10 Padfoot 2012-08-22 07:42:14 UTC
Logs attached. Just noticed right click (with touch input) is not working (using mousetweaks to simulate right click from extended touch). Running xev with evdev 2.7.2 produced button 1 & 3 press and release events with extended touch. With 2.7.3 xev only produced a button 1 event. Cheers.
Comment 11 Peter Hutterer 2012-08-22 22:33:42 UTC
please always make sure that attachments are in text/plain format (where appropriate). please grab evemu and record this device, both the device description and some events that make these bugs appear. Then attach them here, I need to reproduce this locally to debug. http://people.freedesktop.org/~whot/evemu/
Comment 12 Padfoot 2012-08-23 08:02:00 UTC
Created attachment 66007 [details] evemu device description evdev 2.7.2
Comment 13 Padfoot 2012-08-23 08:02:57 UTC
Created attachment 66008 [details] evemu device events evdev 2.7.2
Comment 14 Padfoot 2012-08-23 08:03:40 UTC
Created attachment 66009 [details] evemu device description evdev 2.7.3
Comment 15 Padfoot 2012-08-23 08:04:24 UTC
Created attachment 66010 [details] evemu device events evdev 2.7.3
Comment 16 Padfoot 2012-08-23 08:15:11 UTC
evemu files attached. The gtk menu button issue I am only able to replicate in my DM (lightdm) so do not have that event recorded. The event files have recorded: 1. an anti-clockwise circle (easystroke trigger for scroll) followed by a scroll event in thunar filemanager (2.7.2 the scroll was triggered, 2.7.3 the scroll was not triggered) 2. a left click on the desktop 3. an extended left click on the desktop which triggers a right click event (right click triggered in 2.7.2, not triggered in 2.7.3) I haven't got any data on the Evdev Axes Swap and Evdev Axis Inversion issue unless there is a way to record this that you can advise me on. The recordings both use the egalax binary driver and xorg-server-1.12.3, xorg-server-devel-1.12.3, xorg-server-xephyr-1.12.3, xorg-server-common-1.12.3 and kernel-3.4.4 The focus stealing issue appears to have resolved itself (must have been related to a different package since upgraded).
Comment 17 Peter Hutterer 2012-08-24 06:44:03 UTC
I'm really confused by this statement: > The recordings both use the egalax binary driver and xorg-server-1.12.3 where exactly does this binary driver sit and what device does it control? how is this configured, are you actually using evdev for the device? if so, why do you talk of the binary driver?
Comment 18 Padfoot 2012-08-24 08:33:31 UTC
My device is an eGalax multitouch screen. Without the binary driver, the touch device is configured as a touchscreen using the evdev driver and even though it reports multitouch axes, only single touch is available. The binary driver uses an xorg.conf file to stop the creation of a generic touch device and instead creates 2 virtual devices (single and multi) using the evdev driver to provide single touch and multitouch devices. I guess the binary driver sits between the raw kernel events and evdev to generate the multitouch events that evdev alone currently does not do with this device. xorg.conf file attached. Have a look at the Xorg logs attached and grep eGalax to see how the device is configured both with and without the binary driver. Hope this clarifies it for you, bearing in mind, the issues persist regardless of the use or not of the binary driver. Cheers.
Comment 20 Padfoot 2012-08-28 07:07:13 UTC
Just confirming, with the xorg-server packages upgraded to 1.12.4, the evdev 2.7.3 issues still persist. Cheers.
Comment 21 Peter Hutterer 2012-08-30 05:23:48 UTC
ok, I have no idea what could cause this. I'd need you to bisect this. Should be easy enough, there are only 3 commits in 2.7.3 git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-input-evdev cd xf86-input-evdev git checkout -b evdev-2.7-branch origin/evdev-2.7-branch ./autogen.sh --prefix=/usr make && sudo make install then restart your server, make sure the problem persists. Once done, git bisect start git bisect good xf86-input-evdev-2.7.2 git bisect bad xf86-input-evdev-2.7.3 and re-build and install for each version. Once tested, run git bisect good or git bisect bad to note the commit. Let me know which commit broke it for you.
Comment 22 Padfoot 2012-08-30 07:49:19 UTC
Following your instructions, I got to the first commit (basically as far as git bisect good) would take me, and it was still 'broken' The first commit was commit 777cfa148f8b5febaab1330e8df791f2188c046b which I believe was fix broken button mapping. Input axis swapping and inverting still does not work, and touch events as previously described are not working. Hope this helps. Cheers
Comment 23 Padfoot 2012-08-30 09:04:44 UTC
Ok, found the culprit. Forget my last message. As a matter of interest, I rebuilt 2.7.2 from source, installed it and, lo and behold, I still had the problems. Rebuilt again, but this time without MTDEV, and it is fixed. So it is the building with MTDEV support that is causing all the issues with touch events and borking axis inversion/swapping. Cheers.
Comment 24 Peter Hutterer 2012-08-30 11:50:42 UTC
if you build without MTDEV, evdev is built without multitouch support. http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/configure.ac?h=evdev-2.7-branch#n57(In reply to comment #22) > Following your instructions, I got to the first commit (basically as far as git > bisect good) would take me, and it was still 'broken' > > The first commit was commit 777cfa148f8b5febaab1330e8df791f2188c046b which I > believe was fix broken button mapping. Did you test 2.7.2 as well? if not, can you bisect back further (start with 2.7.0 as "good" and go from there).
Comment 25 Padfoot 2012-08-31 07:28:37 UTC
Ok, can confirm it is mtdev causing the breakage. Tested as follows: Build xf86-input-evdev 2.7.2 & 2.7.3 without mtdev support: No issues at all. Using egalax driver, I have multitouch support Not using egalax driver, I have no multitouch support Build xf86-input-evdev 2.7.2 & 2.7.3 with mtdev support: Evdev Axis Inversion and Evdev Axes Swap are broken Touch events are broken Using egalax driver, I have multitouch support Not using egalax driver, I have no multitouch support So it definitely is mtdev support causing all the problems. Cheers.
Comment 26 David López 2012-09-01 14:56:02 UTC
Hi. I have an ekoore perl (wetab, exopc) with an egalax touchscreen. I used Lubuntu 12.04 precise and I also had the same touchscreen problems that padfoot comment: random focus, scroll doesn't work with easystroke, evdev rotation properties are ignored. I'm not an expert user, I don't know if ubuntu precise evdev driver was built with mtdev enabled or disabled. Now I've recently moved to Arch and also suffer the same problems with evdev 2.7.3 driver from repo. Downgrading to 2.7.2, 2.7.1 or 2.7.0 drivers from snapshots in ARM solve all these problems. By the way, I think that the focus problem is also related with easystroke, disabling it solve the problem. I use easystroke 0.5.4 compiled from sources, lxde and onboard from official repos. Wish this information helps.
Comment 27 Padfoot 2012-09-09 23:29:55 UTC
I have sent a bug report to the mtdev team: -------- Original Message -------- Subject: BUG REPORT mtdev breaks xrandr axis mapping and evdev touch events Date: Mon, 10 Sep 2012 09:21:10 +1000 From: Padfoot To: firstname.lastname@example.org Hi, Sorry if this is the wrong place to report bugs, but it is the only contact I could find for the mtdev project. I am using Arch linux with kernel version 3.5, xf86-input-evdev-2.7.3 and have tried both mtdev-1.1.2 and mtdev-1.1.3 on an Acer Iconia Tab device with an eGalax multitouch touchscreen. When xf86-input-evdev is built with mtdev support: (see the following xf86-input-evdev bug report: https://bugs.freedesktop.org/show_bug.cgi?id=53669) xRandR axis mapping is broken. When the device is rotated and evdev axis inversion / evdev axes swap properties are set for the input device, xinput is reporting the change in the X server, yet the modified axes are ignored - input events are treated as if the device is not rotated. Touch events are broken. This one is hard to explain, but it would seem certain touch events are not passed back to evdev to act upon. Using tools such as mousetweaks and easystroke to allow for gesture support, events such as scroll and right click are not triggered, and sometimes left click events are not completely passed through (eg clicking on a gtk menu button will only highlight the button, then clicking another widget then back on the menu button finally triggers the menu to open - maybe only a touch down event is generated and not the corresponding touch up) Please see the bug report linked above for further information as reported to the upstream xorg devs. Rebuilding xf86-input-evdev without mtdev support resolves all issues. Please let me know if there is anything I can do to assist in resolving this issue. Thanks.
Comment 28 David López 2012-09-11 13:42:17 UTC
A little update. I've tested 2 versions of evdev driver - xf86-input-evdev 2.7.3 from Arch repo, mtdev is a dependence - xf86-input-evdev 2.7.3 built from Arch's PKGBUILD removing 'mtdev' as dependence The 'random focus' problem appears in the mtdev driver if easystroke is in use for the egalax touchscreen. The problem disappear closing easystroke (or disabling eGalax Inc. USB Touchscreen in easystroke's options).
Comment 29 David López 2012-09-11 13:45:36 UTC
(In reply to comment #28) > A little update. I've tested 2 versions of evdev driver > > - xf86-input-evdev 2.7.3 from Arch repo, mtdev is a dependence > - xf86-input-evdev 2.7.3 built from Arch's PKGBUILD removing 'mtdev' as > dependence > > The 'random focus' problem appears in the mtdev driver if easystroke is in use > for the egalax touchscreen. The problem disappear closing easystroke (or > disabling eGalax Inc. USB Touchscreen in easystroke's options). I forget to comment that I've tested with 2 different easystroke's versions: - easystroke 0.5.5.1 from Arch's repo - easystroke 0.5.4 built from sources replacing 'lboost_serialization_mt' with 'lboost_serialization' in Makefile. Both cases with the same result: easystroke+xf86-input-evdev with mtdev support: focus jumping easystroke+xf86-input-evdev without mtdev support: focus is OK
Comment 30 Thomas Lübking 2012-09-22 19:01:01 UTC
The issue seems to be, that the touch devices only generate absolute input events but swap/invert is only handled by relative ones (i printed me that to stderr, so it's not just a guess) I however don't know who's to blame here (egalax, mtdev, evdev) but stuff like xinput --set-prop "$TOUCH_DEVICE" "Evdev Axes Swap" 1 xinput --set-prop "$TOUCH_DEVICE" "Evdev Axis Inversion" 1, 0 is completely pointless with this setup. "Interestingly", my real mouse does not have any swapping/inversion flags but rotates with xrandr calls. Peter, can you point the responsible layer, so we can address them with the information?
Comment 31 Padfoot 2012-09-29 00:11:49 UTC
A little more information for you. The egalax binary driver is built with automatic xrandr rotation detection. To use this feature, the driver needs to have a config file option set and the driver must be started only after X has been started. I tried this feature using evdev-2.7.3 with MTDEV support, and input co-ordinate rotation now works, as the egalax driver is detecting the xrandr rotation and modifying the input co-ordinates appropriately. So while not a complete solution to this issue (as other touchscreen devices might not have this feature - especially if they do not utilise a device specific driver) it does provide a partial resolution for myself. The "focus" issue I had mentioned earlier actually turned out to be related to https://bugs.freedesktop.org/show_bug.cgi?id=54353. I am executing: $ 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 on startup and that issue is also resolved. The only issue remaining after doing the above is the touch events no longer working as expected (ie, scroll, right click etc) Cheers.
Comment 32 Peter Hutterer 2016-11-28 04:40:04 UTC
This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it. Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.