Bug 97989 - xf86-input-libinput-0.20.0: Touchpad stops working with new option TappingButtonMap=lmr
Summary: xf86-input-libinput-0.20.0: Touchpad stops working with new option TappingBut...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/libinput (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-30 15:33 UTC by Jose
Modified: 2016-10-18 02:08 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log with "lmr" option (35.32 KB, text/plain)
2016-09-30 15:33 UTC, Jose
no flags Details
xinput list-props (1.37 KB, text/plain)
2016-10-13 17:30 UTC, nl6720
no flags Details
xinput list-props (XPS 15 9550) (1.61 KB, text/plain)
2016-10-13 20:49 UTC, Jose
no flags Details

Description Jose 2016-09-30 15:33:43 UTC
Created attachment 126905 [details]
Xorg.0.log with "lmr" option

I'm running archlinux on an XPS 15 9550. This is the line from dmesg about the touchpad:
input: DLL06E4:01 06CB:7A13 Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-DLL06E4:01/0018:06CB:7A13.0001/input/input12

I just installed xf86-input-libinput-0.20.0 (with libinput-1.5.0) and wanted to test the new functionality to configure multi-finger tap mapping. The Touchpad stopped working when i enabled the "lmr" tap button map.

I do this with this file: /etc/X11/xorg.conf.d/30-touchpad.conf
Section "InputClass"
        Identifier "Touchpad"
        MatchIsTouchpad "on"
        Driver "libinput"

        Option "Tapping" "on"
	Option "TappingButtonMap" "lmr"
	Option "AccelSpeed" "1.0"
	Option "TappingDragLock" "on"
EndSection


When I restart X, the Touchpad does not seem to be working at all. No mouse movement, no clicks, nothing. I don't see any errors anywhere.

I comment out the new option TappingButtonMap, restart X and the Touchpad works fine, defaulting to the usual lrm tab behaviour.

I'll attach the Xorg log although I don't see anything weird in it. Actually, the diff between with and without the new option doesn't give us much:

--- Xorg.0.log.defaultButtonMap	2016-09-30 10:12:37.160347552 -0500
+++ Xorg.0.log.lmrButtonMap	2016-09-30 10:12:53.247171749 -0500
@@ -13,7 +13,7 @@
 rs: (--) probed, (**) from config file, (==) default setting,
  line, (!!) notice, (II) informational,
 ) error, (NI) not implemented, (??) unknown.
-Log file: "/var/log/Xorg.0.log", Time: Fri Sep 30 09:56:01 2016
+Log file: "/var/log/Xorg.0.log", Time: Fri Sep 30 09:57:40 2016
 Using config directory: "/etc/X11/xorg.conf.d"
 Using system config directory "/usr/share/X11/xorg.conf.d"
 No Layout section.  Using the first Screen section.
@@ -380,6 +380,7 @@
 input device 'DLL06E4:01 06CB:7A13 Touchpad', /dev/input/event10 is a touchpad
 Option "Tapping" "on"
 Option "TappingDragLock" "on"
+Option "TappingButtonMap" "lmr"
 Option "AccelSpeed" "1.0"
 Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-DLL06E4:01/0018:06CB:7A13.0001/input/input12/event10"
 XINPUT: Adding extended input device "DLL06E4:01 06CB:7A13 Touchpad" (type: TOUCHPAD, id 17)
Comment 1 pl.frnk 2016-10-09 08:14:45 UTC
Same dead mouse pointer running Arch Linux on an old Samsung N130 using
- linux 4.7.6,
- libinput 1.5.0
- xf86-input-libinput 0.20.0.

Debugging works using two-finger middle click:
libinput-debug-events --enable-tap --set-tap-map=lmr --device /dev/input/event6
-event6 	DEVICE_ADDED     SynPS/2 Synaptics TouchPad        seat0 default group1 cap:p	size 50.99/24.12mm tap(dl off) left scroll-nat scroll-2fg-edge dwt-on
 event6 	POINTER_BUTTON    +1.45s	BTN_MIDDLE (274) pressed, seat count: 1
 event6 	POINTER_BUTTON    +1.45s	BTN_MIDDLE (274) released, seat count: 0

### dmesg ###
input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input13

### /etc/X11/xorg.conf.d/30-touchpad.conf ###
Section "InputClass"
        Identifier "Touchpad"
        MatchIsTouchpad "on"
        Driver "libinput"
        Option "TappingButtonMap" "lmr"
EndSection

### libinput-list-devices ###
Device:           SynPS/2 Synaptics TouchPad
Kernel:           /dev/input/event6
Group:            6
Seat:             seat0, default
Size:             50.99x24.12mm
Capabilities:     pointer 
Tap-to-click:     disabled
Tap-and-drag:     enabled
Tap drag lock:    disabled
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   *two-finger edge 
Click methods:    none
Disable-w-typing: enabled
Accel profiles:   none
Rotation:         n/a
Comment 2 Peter Hutterer 2016-10-13 00:51:19 UTC
sorry for the delay, I was on holidays.

I can't reproduce this here, the touchpad works fine with the options in place (expected, I did test this before pushing :) What is the output of xinput list-props <device name> ?  does it show the properties enabled as expected?

does xinput test-xi2 show any events for the touchpad? judging by the log, the touchpad should be just fine.
Comment 3 nl6720 2016-10-13 17:29:24 UTC
Same issue for me with HP ProBook 450 G2.

Arch Linux
linux 4.7.6-1
libinput 1.5.0-1
xf86-input-libinput 0.20.0-1

psmouse serio3: synaptics: Touchpad model: 1, fw: 7.5, id: 0x1e0b1, caps: 0xf00173/0x640000/0xa2400/0x0, board id: 2654, fw id: 1323623
input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio3/input/input18

/etc/X11/xorg.conf.d/30-touchpad.conf
Section "InputClass"
    Identifier "touchpad"
    Driver "libinput"
    MatchIsTouchpad "on"
    Option "Tapping" "on"
    Option "TappingButtonMap" "lmr"
EndSection


`xinput test-xi2` doesn't show any events from touchpad.
Comment 4 nl6720 2016-10-13 17:30:41 UTC
Created attachment 127276 [details]
xinput list-props
Comment 5 Jose 2016-10-13 20:49:38 UTC
Created attachment 127278 [details]
xinput list-props (XPS 15 9550)

'xinput test-xi2' doesn't report any events from the touchpad and neither does xev.
Comment 6 Jose 2016-10-13 21:02:23 UTC
As I mentioned before the touchpad works fine when the "TappingButtonMap" line is commented out.

These are the differences in the output of `xinput list-props` between those two cases:

--- xinput-list-props-default.log	2016-10-13 14:51:35.859922992 -0600
+++ xinput-list-props.log	2016-10-13 14:45:30.084367459 -0600

-	libinput Tapping Button Mapping Enabled (305):	1, 0
+	libinput Tapping Button Mapping Enabled (305):	0, 1

-	libinput Send Events Mode Enabled (263):	0, 0
+	libinput Send Events Mode Enabled (263):	1, 0
Comment 7 Peter Hutterer 2016-10-13 21:42:00 UTC
(In reply to Jose from comment #6)
> -	libinput Send Events Mode Enabled (263):	0, 0
> +	libinput Send Events Mode Enabled (263):	1, 0

where does this come from? this is the libinput equivalent to "device is disabled now" which explains why it's dead. but why is this being set? could it be some desktop environment interfering here?
Comment 8 Jose 2016-10-14 03:01:58 UTC
I started X without a desktop environment, using startx (it gave me a black screen with 3 xterms), and the mousepad was still not working.

Just in case I'll mention that the display manager I use is lightdm and the desktop environment is cinnamon. The mousepad is already not working inside lightdm, before I log.
Comment 9 Peter Hutterer 2016-10-14 03:44:39 UTC
found it, it was a typo. and it was my DE that was 'interfering', apparently it enabled the device unconditionally, so the obvious error in the patch got papered over.

commit 6318ac420b644c7f7a6f2c8e47a64238a4afebeb
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Oct 14 13:34:56 2016 +1000

    Fix tap button map option handling
Comment 10 Jose 2016-10-17 19:30:09 UTC
Peter: I was gonna test your fix and confirm it works in my system but I can't find it anywhere. It's not in the git repo.
Comment 12 Jose 2016-10-18 02:08:50 UTC
Thanks for the link. Like the dummy I am I was looking for it in libinput's git repo.

Anyway, I can confirm that the patch fixes the issue on my end. 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.