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.

Created attachment 125125 [details]
udevadm info --export-db

$ 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

(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?

Created attachment 125129 [details]
dmesg.txt

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.

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.

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.

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.