Hi, I'm running Debian/testing with xserver-xorg-input-libinput 0.23.0-2. xinput reports the following devices on my Dell Latitude E7470: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS DualPoint TouchPad id=12 [slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS DualPoint Stick id=13 [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)] ↳ Power Button id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ Integrated_Webcam_HD id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=11 [slave keyboard (3)] ↳ Dell WMI hotkeys id=14 [slave keyboard (3)] ↳ DELL Wireless hotkeys id=15 [slave keyboard (3)] This Laptop has three "mouse buttons" above the touchpad and two below. I think (but I'm not certain) that the upper three button row is associated somehow with the DualPoint Stick and the lower two button with the touchpad. So far it was possible to use them both and I preferred the upper row together with the touchpad. So I could hold down the left button and select text with the touchpad. Since the last libinput update that only works if I use the left button below the touchpad. Using the upper left button and the stick still allows me to select text, so I assume the upper row of buttons is somehow disable when the touchpad detects input events. I skimmed through the libinput manpage but could not find anything that sound like something I could use to configure this behaviour. Is there a way to keep both button rows enabled together with the touchpad? If not count that bug as a feature request, would be really cool to get this behaviour back which was there in version 0.22.x.
any chance you can bisect this? not sure what could've caused that, it certainly wasn't anything intentional.
Hi, is there some kind of quick & dirty documentation on how to compile and switch only this one driver from the xorg stack to bisect this issue? Or do I have to build the whole xorg stack from source? Anyway a coworker running Fedora on the same laptop model confirmed the issue, so it's at least not specific to some parts of the Debian xorg stack.
if you have the required build-deps installed, you can just do the following: ./configure --prefix=/usr make && sudo make install (I'm pretty sure /usr/ that's the correct prefix for debian) this will overwrite the systemd driver, so it's used the next time round. then you just do the bisect with make install every time and restart X. When you're done, force-reinstall the debian package which will overwrite anything installed by make install process. You can run sudo make uninstall first if you really want to make sure nothing is left. Problem is: this is the X driver, so if something doesn't work you're out of luck. So I recommend setting up your boot process to *not* boot into graphical directly. This way it's easy to recover.
Hello Peter, with help from another coworker (he's using a slightly different Laptop modell but also Dell, similar generation) we now found out that this issue seems to be related to the Linux kernel in use. At least a downgrade from the Debian Linux 4.9 package to 4.8 restores the expected behaviour. Same for me on Debian/testing (what will be stretch) as for one coworker running Debian/jessie with the backports kernel. The coworker using Fedora is also on 4.9 but did not yet try the downgrade yet. So I guess the appropriate way forward is to close the bug here as invalid and report it instead to the kernel maintainer?
CC-ing benjamin, he may be aware of the issue
There has been only 4 commits between v4.8 and v4.9[1]. I don't see anything obvious in those 4 commits that would explain this bug. However, there are some fixes scheduled for v4.10. Could you give a shot at a v4.10-rc7? [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/input/mouse/alps.c -> the 4 from Ben Gamari
Hi, ok I could swiftly try 4.10.0-rc6 from Debian/experimental and I can confirm that the issue is fixed with this release. The coworker with Fedora updated to 4.9.6 this morning (4.9.6 is what the rpm version number reports but the changelog claims the last import to be 4.9.5). The Debian 4.9 linux package is according to the changelog still at 4.9.2, so the fix should be somewhere in the between. Looking at the alps changes we see only https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=6d9b544d88a4a697211062fc2ab2eb0e28c01b13 as a possible alps change and it's in 4.9.6. So if the rpm version of the kernel package in Fedora is correct I think it's likely that this is the relevant fix.
Thanks for confirming that it has been fixed in the kernel already. Closing the bug given that there is nothing more to do :)
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.