Comment 26 for bug 1715479

There are a few issues here that are tangentially related. Please don't submit anymore dmidecode data, it only makes it harder to find the signal in all the noise.

First: libinput-debug-events sits on the side of the X session, it sees the same events but behaves differently because it doesn't see the configuration from X. Think of it of running tail -f on the same file twice, the two instances see the same data but can behave differently depending on what other options are applied.

libinput-debug-events is useful to tell when a bug is caused by libinput, but it doesn't always help with X-specific bugs.

To debug this, we will need an X session and the output of variuos xinput commands, anything else won't help much.

Ok, now let's continue:
 Device Enabled (139): 0

that means the device is disabled at the X level and removes it from the fd set for libinput. The server won't forward any events from a device, even if it did send events to begin with (which it shouldn't, because it was removed). Judging by comment 11, this seems to work.

GNOME toggles the "libinput Send Events Mode Enabled" property to 1 0 (== disabled). That works here (F26 though) but I'll need a confirmation from you that it does that. If not, then this is a gnome issue.

xinput watch-props "Synaptics...", then toggle the checkbox in the control center and see if the value changes.

If it *does* change to 1 0 but the touchpad still generates events, please run
xinput test-xi2 and see what events are actually generated on the X level by the touchpad (keep an eye on the device id in (parenthesis) to identify the touchpad). Let me know how you go with these.