Bug 96969

Summary: Ignore the mute touchpad when synaptics i2c is used
Product: Wayland Reporter: Peter Hutterer <peter.hutterer>
Component: libinputAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: medium CC: benjamin.tissoires, peter.hutterer, russell+freedesktop.org
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: udevadm info --export-db
dmesg.txt

Description Peter Hutterer 2016-07-18 00:57:42 UTC
When we have an i2c touchpad (see e.g. Bug 96925) we have two event nodes. One named "DLL06E4:01 06CB:7A13 Touchpad" (or similar) that is the actual touchpad device. The other one is named "SynPS/2 Synaptics TouchPad" and effectively mute, it never sends events.

This causes user confusion when configuring the device but also makes it appear like we have multiple touch devices (potential dwt issues?).


Russel: please attach the output of udevadm info --export-db so we can figure out how to detect this in userspace.

Benjamin: is this something we can fix in the kernel?
Comment 1 Russell Stuart 2016-07-18 02:24:08 UTC
I looked did at it further, after seeing your comment on LWN about the name "SynPS/2 Synaptics TouchPad" coming from the kernel.  You were correct - it is what is returned by the EVIOCGNAME, ioctl.  But that didn't look like a name that would be hardwired into the kernel.

Turns out "SynPS/2 Synaptics TouchPad" is hanging off the 8042, or whatever passes for that in a modern south bridge.  The 8042 is the PS/2 controller for the mouse and keyboard, and mice support Plug and Play stuff - like reading back the name.  So my DELL XPS 9550 touchpad has interfaces to two buses - i2c and the 8042.
Comment 2 Russell Stuart 2016-07-18 02:25:01 UTC
Created attachment 125125 [details]
udevadm info --export-db
Comment 3 Russell Stuart 2016-07-18 02:45:53 UTC
$ ls -og /sys/class/input/mouse0
lrwxrwxrwx 1 0 Jul 18 12:32 /sys/class/input/mouse0 -> ../../devices/platform/i8042/serio1/input/input2/mouse0

$ cat /sys/class/input/input2/name
SynPS/2 Synaptics TouchPad

$ ls -og /sys/class/input/mouse2
lrwxrwxrwx 1 0 Jul 18 12:32 /sys/class/input/mouse2 -> ../../devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-DLL06E4:01/0018:06CB:7A13.0002/input/input14/mouse2

$ cat /sys/class/input/input14/name
DLL06E4:01 06CB:7A13 Touchpad
Comment 4 Benjamin Tissoires 2016-07-18 07:30:02 UTC
(In reply to Peter Hutterer from comment #0)
> Benjamin: is this something we can fix in the kernel?

Not that I know of. Last time I checked, there was no information from the PS/2 node that told us that there was an other bus in use.

However my memories might be wrong, so Russel, could you please attach a dmesg from the boot so we can see which capabilities are exported under PS/2?
Comment 5 Russell Stuart 2016-07-18 08:38:53 UTC
Created attachment 125129 [details]
dmesg.txt
Comment 6 Benjamin Tissoires 2016-07-19 14:36:49 UTC
Thanks for the dmesg. Looks like the touchpad also advertises itself as connected to an other bus. So theoretically, we should be able to remove the PS/2 node at some point.

I need to check if it's safe to disable those touchpad by default first.
Comment 7 Peter Hutterer 2016-08-01 05:33:23 UTC
Benjamin and I discussed that privately and the outcome is that we'll have to solve this in userspace. To get the kernel to drop the mute device requires a bit of effort, especially in light of the various compile-time options. This is simply not worth it.
Comment 8 Russell Stuart 2016-08-01 05:50:04 UTC
Whether it's worth the effort surely depends on now many manufacturers put the same device on two different buses, reporting two different ID strings, but one of which doesn't work.  What Dell has done here looks slightly like a decidedly weird design decision to me, one that please $deity should be very rare.
Comment 9 Peter Hutterer 2016-08-01 06:19:01 UTC
I had a look at this for libinput and this would be a lot more complicated than is currently warranted for. From a code check, both devices correctly pair wih the built-in keyboard for the disable-while-typing feature. So the only negative effect we currently have is that we have a second touchpad that doesn't send events. That effect is largely cosmetic (though it can cause end-user confusion).

To fix this in libinput we'd need to have some udev tagging in place (to tag *both* devices) and run-time handling of the devices to drop the mute device. since we can't guarantee the discovery order of the devices we can't just solve this with a udev rule/hwdb entry.

libinput doesn't have the bits in place yet to fully drop a device if it's not removed by the kernel. And we can't *remove* it anyway when the path interface is in use (in the Xorg case), we can only mute it - which isn't necessary for an already mute device.

There is one option around it by using DMI matches to simply tag any serial synaptics device on the matched DMI platforms but that would have the same side-effects as the kernel solution - custom kernels could break things.

So for now I'm closing this as WONTFIX. If someone wants to put the effort in to make this work correctly we can revisit, but this is unlikely to happen.

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.