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.
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.
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.
I have xorg-server/-common/-xephyr/-devel packages held at 1.12.3 as the current version in the Arch repos (22.214.171.1241) 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?
xorg-server-126.96.36.1991, xorg-server-devel-188.8.131.521, xorg-server-xephyr-184.108.40.2061, xorg-server-common-220.127.116.111, 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)
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.
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?
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.
Created attachment 65936 [details]
Xorg.0.log without binary driver
Created attachment 65937 [details]
Xorg.0.log with binary driver
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.
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.
Created attachment 66007 [details]
evemu device description evdev 2.7.2
Created attachment 66008 [details]
evemu device events evdev 2.7.2
Created attachment 66009 [details]
evemu device description evdev 2.7.3
Created attachment 66010 [details]
evemu device events evdev 2.7.3
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).
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?
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.
Created attachment 66053 [details]
Just confirming, with the xorg-server packages upgraded to 1.12.4, the evdev 2.7.3 issues still persist.
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
git checkout -b evdev-2.7-branch origin/evdev-2.7-branch
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.
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.
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.
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).
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.
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.
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
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:
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
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).
(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
> 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
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?
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)
on May 31, 2016 at 19:51:28.
(provided by the Example extension).