Touchpad won't stay disabled after resuming from suspend

[Brian Murray]

I've disabled my touchpad using the mouse and touchpad control panel however it does not last very long i.e. after I've disabled it, it somehow becomes enabled even though the control panel continues to show it as disabled.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: gnome-shell 3.25.91-0ubuntu3
ProcVersionSignature: Ubuntu 4.12.0-12.13-generic 4.12.8
Uname: Linux 4.12.0-12-generic x86_64
ApportVersion: 2.20.7-0ubuntu1
Architecture: amd64
CurrentDesktop: GNOME
Date: Wed Sep 6 12:47:26 2017
DisplayManager: gdm3
InstallationDate: Installed on 2016-01-22 (593 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160117)
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

[Matt (matt-redhat-bugs)]

laptop: Lenovo T460P

O/S: fedora 25, fully updated

BIOS setting: Touchpad: off
// already filed a bug with Lenovo as a BIOS error

gnome-control-center mouse: Touchpad: off

# libinput-debug-events
-event2 DEVICE_ADDED Power Button seat0 default group1 cap:k
-event7 DEVICE_ADDED Video Bus seat0 default group2 cap:k
-event6 DEVICE_ADDED Video Bus seat0 default group2 cap:k
-event1 DEVICE_ADDED Sleep Button seat0 default group3 cap:k
-event4 DEVICE_ADDED Yubico Yubico Yubikey II seat0 default group4 cap:k
-event10 DEVICE_ADDED Integrated Camera seat0 default group5 cap:k
-event3 DEVICE_ADDED AT Translated Set 2 keyboard seat0 default group6 cap:k
-event5 DEVICE_ADDED SynPS/2 Synaptics TouchPad seat0 default group7 cap:pg size 100x58mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on
-event8 DEVICE_ADDED TPPS/2 IBM TrackPoint seat0 default group8 cap:p left scroll-nat scroll-button
-event9 DEVICE_ADDED ThinkPad Extra Buttons seat0 default group9 cap:k
-event5 POINTER_AXIS +2.79s vert 3.14* horiz 0.00 (finger)
 event5 GESTURE_SWIPE_BEGIN +4.04s 3
 event5 GESTURE_SWIPE_UPDATE +4.04s 3 0.00/ 1.87 ( 0.00/15.75 unaccelerated)

I'm assuming that when I touch the touchpad, this should NOT happen.

There is a bigger picture here and that is when my palm rests too heavy on the touchpad, it messes with the clicking of my mouse. I'll grab tabs and scroll bars and won't let go until I click on them again.

I can reproduce this by putting 3 fingers on the touchpad and clicking on a scoll bar or tab and it will start messing up in short order.

[Peter (peter-redhat-bugs)]

libinput-debug-events is unrelated to the gnome session, it creates a new context and the gnome settings have no effect on it.

is this in an X session? If so, what does xinput list-props "SynPS/2 Synaptics TouchPad" show after disabling the touchpad in gnome?

for the palm issues, etc. please file a separate bug, thanks.

[Matt (matt-redhat-bugs)]

Yes, this in an X session.

$ xinput list-props "SynPS/2 Synaptics TouchPad"
unable to find device SynPS/2 Synaptics TouchPad

will be filing seperate bug for other issues.

thanks.

[Peter (peter-redhat-bugs)]

run xinput list to find the device name, I wonder if I mistyped anything. then substitute the device name with the one for the touchpad. if you see devices like "wayland pointer" etc, then you're under wayland, in which case the xinput approach won't work. log out and back in as Gnome on Xorg on the user's login screen (click the gear icon), then see if you can reproduce it there.

[Matt (matt-redhat-bugs)]

$ loginctl
   SESSION UID USER SEAT
        c1 42 gdm seat0
         2 1000 username seat0

$ loginctl show-session 2 -p Type
Type=x11

$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech Logitech USB Optical Mouse id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=17 [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)]
    ↳ Video Bus id=8 [slave keyboard (3)]
    ↳ Sleep Button id=9 [slave keyboard (3)]
    ↳ Logitech USB Keyboard id=10 [slave keyboard (3)]
    ↳ Logitech USB Keyboard id=11 [slave keyboard (3)]
    ↳ Yubico Yubico Yubikey II id=12 [slave keyboard (3)]
    ↳ Integrated Camera id=14 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=15 [slave keyboard (3)]
    ↳ ThinkPad Extra Buttons id=18 [slave keyboard (3)]

$ xinput list-props "SynPS/2 Synaptics TouchPad"
Device 'SynPS/2 Synaptics TouchPad':
 Device Enabled (141): 1
 Coordinate Transformation Matrix (143): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 Device Accel Profile (272): 0
 Device Accel Constant Deceleration (273): 1.000000
 Device Accel Adaptive Deceleration (274): 1.000000
 Device Accel Velocity Scaling (275): 10.000000
 Device Product ID (265): 2, 7
 Device Node (264): "/dev/input/event6"
 Evdev Axis Inversion (302): 0, 0
 Evdev Axis Calibration (303): <no items>
 Evdev Axes Swap (304): 0
 Axis Labels (305): "Abs MT Position X" (299), "Abs MT Position Y" (300), "Abs MT Pressure" (301), "Abs Tool Width" (298), "None" (0), "None" (0), "None" (0)
 Button Labels (306): "Button Left" (144), "Button Unknown" (294), "Button Unknown" (294), "Button Wheel Up" (147), "Button Wheel Down" (148)
 Evdev Scrolling Distance (307): 0, 0, 0
 Evdev Middle Button Emulation (308): 0
 Evdev Middle Button Timeout (309): 50
 Evdev Middle Button Button (310): 2
 Evdev Third Button Emulation (311): 0
 Evdev Third Button Emulation Timeout (312): 1000
 Evdev Third Button Emulation Button (313): 3
 Evdev Third Button Emulation Threshold (314): 20
 Evdev Wheel Emulation (315): 0
 Evdev Wheel Emulation Axes (316): 0, 0, 4, 5
 Evdev Wheel Emulation Inertia (317): 10
 Evdev Wheel Emulation Timeout (318): 200
 Evdev Wheel Emulation Button (319): 4
 Evdev Drag Lock Buttons (320): 0

[Peter (peter-redhat-bugs)]

You're using the evdev driver and that usually means that the touchpad uses the synaptics driver. Both are effectively deprecated now, and gnome has dropped support for those so the gnome checkbox does nothing but look pretty.

Not sure why you're using evdev for the touchpad, do you have xorg-x11-drv-libinput installed? Check /etc/X11/xorg.conf.d for any leftover snippets, remove any mate or cinnamon packages if you have any.

[Peter (peter-redhat-bugs)]

also, is this still an issue now that you tried out 1.7.2? (see bug #1433033)

[Matt (matt-redhat-bugs)]

I pulled the latest libinput out of rawhide. I don't see 1.7.2 as you mentioned. am I missing something?

# rpm -qa |grep libinput
libinput-1.7.1-4.fc27.x86_64
xorg-x11-drv-libinput-0.25.1-1.fc27.x86_64

# rpm -qa |grep synaptic
#

# rpm -qa |grep evdev
libevdev-1.5.6-1.fc25.x86_64
xorg-x11-drv-evdev-2.10.5-1.fc25.x86_64

# rpm -e libevdev xorg-x11-drv-evdev
error: Failed dependencies:
 libevdev.so.2()(64bit) is needed by (installed) libinput-1.7.1-4.fc27.x86_64
 libevdev.so.2(LIBEVDEV_1)(64bit) is needed by (installed) libinput-1.7.1-4.fc27.x86_64

# ls /etc/X11/xorg.conf.d/
00-keyboard.conf

Problem exists in both wayland and X11.

[Peter (peter-redhat-bugs)]

(In reply to Matt Jamison from comment #7)
> I pulled the latest libinput out of rawhide. I don't see 1.7.2 as you
> mentioned. am I missing something?

should definitely be there, maybe some mirror issue?
https://koji.fedoraproject.org/koji/buildinfo?buildID=888012

> # rpm -e libevdev xorg-x11-drv-evdev
> error: Failed dependencies:
> libevdev.so.2()(64bit) is needed by (installed) libinput-1.7.1-4.fc27.x86_64
> libevdev.so.2(LIBEVDEV_1)(64bit) is needed by (installed)
> libinput-1.7.1-4.fc27.x86_64

libevdev is a low-level library that libinput uses as well, if anything only
remove xorg-x11-drv-evdev. but witout any config snippet you should be able
to just leave it there, libinput will override it anyway.

> Problem exists in both wayland and X11.

in the X session: do xinput watch-props "touchpad device name" and toggle the touchpad off setting in gnome, does anything change?

[Matt (matt-redhat-bugs)]

problem still persists with no change.

putting 3 fingers on the disabled touchpad still messes up clicking.

$ rpm -qa |grep libinput
libinput-1.7.2-2.fc26.x86_64
xorg-x11-drv-libinput-0.25.1-1.fc27.x86_64

$ rpm -qa |grep evdev
libevdev-1.5.7-1.fc27.x86_64

$ loginctl
   SESSION UID USER SEAT
        c1 42 gdm seat0
         2 1000 jamisonm seat0

$ loginctl show-session 2 -p Type
Type=wayland

WITH TOUCHPAD DISABLED:
$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ xwayland-pointer:13 id=6 [slave pointer (2)]
⎜ ↳ xwayland-relative-pointer:13 id=7 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ xwayland-keyboard:13 id=8 [slave keyboard (3)]

WITH TOUCHPAD ENABLED:
$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ xwayland-pointer:13 id=6 [slave pointer (2)]
⎜ ↳ xwayland-relative-pointer:13 id=7 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ xwayland-keyboard:13 id=8 [slave keyboard (3)]

I don't see a touchpad device name to run xinput watch-props on.

[Peter (peter-redhat-bugs)]

You're running under wayland, where xinput will have no real effect. You need to start an X session to be able to debug this.

[Vladyslav (vladyslav-redhat-bugs)]

I can confirm this bug on the same configuration (Fedora 25 and T460p).

The only way to really turn off the touchpad is to issue

$ xinput set-prop 'SynPS/2 Synaptics TouchPad' 'Device Enabled' 0

I'm using X session (not Wayland), so for me this always works.

[Matt (matt-redhat-bugs)]

$ loginctl
   SESSION UID USER SEAT
         2 1000 <username> seat0
        c1 42 gdm seat0

  $ loginctl show-session 2 -p Type
Type=x11

$ xinput set-prop 'SynPS/2 Synaptics TouchPad' 'Device Enabled' 0

$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=14 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad 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)]
    ↳ Video Bus id=8 [slave keyboard (3)]
    ↳ Sleep Button id=9 [slave keyboard (3)]
    ↳ Yubico Yubico Yubikey II id=10 [slave keyboard (3)]
    ↳ Integrated Camera id=11 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
    ↳ ThinkPad Extra Buttons id=15 [slave keyboard (3)]

Problem still persists.

[Vladyslav (vladyslav-redhat-bugs)]

Strange. Here is what I have

$ loginctl

   SESSION UID USER SEAT
         2 1000 <username> seat0
        c1 42 gdm seat0

$ loginctl show-session 2 -p Type
Type=x11

$ uname -a
Linux elektron 4.10.15-200.fc25.x86_64 #1 SMP Mon May 8 18:46:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ xinput list

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ Video Bus id=7 [slave keyboard (3)]
    ↳ Sleep Button id=8 [slave keyboard (3)]
    ↳ Power Button id=6 [slave keyboard (3)]
    ↳ Integrated Camera id=9 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]
    ↳ ThinkPad Extra Buttons id=12 [slave keyboard (3)]

$ sudo dmidecode -t system | head -n 14

# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x000C, DMI type 1, 27 bytes
System Information
 Manufacturer: LENOVO
 Product Name: 20FW000DPG
 Version: ThinkPad T460p
 Serial Number: -----------
 UUID: ------------------------------------
 Wake-up Type: Power Switch
 SKU Number: LENOVO_MT_20FW_BU_Think_FM_ThinkPad T460p
 Family: ThinkPad T460p

$ sudo dmidecode -t bios

# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x000B, DMI type 0, 24 bytes
BIOS Information
 Vendor: LENOVO
 Version: R07ET73W (2.13 )
 Release Date: 12/20/2016
 Address: 0xE0000
 Runtime Size: 128 kB
 ROM Size: 16384 kB
 Characteristics:
  PCI is supported
  PNP is supported
  BIOS is upgradeable
  BIOS shadowing is allowed
  Boot from CD is supported
  Selectable boot is supported
  EDD is supported
  3.5"/720 kB floppy services are supported (int 13h)
  Print screen service is supported (int 5h)
  8042 keyboard services are supported (int 9h)
  Serial services are supported (int 14h)
  Printer services are supported (int 17h)
  CGA/mono video services are supported (int 10h)
  ACPI is supported
  USB legacy is supported
  BIOS boot specification is supported
  Targeted content distribution is supported
  UEFI is supported
 BIOS Revision: 2.13
 Firmware Revision: 1.4

Handle 0x0024, DMI type 13, 22 bytes
BIOS Language Information
 Language Description Format: Abbreviated
 Installable Languages: 1
  en-US
 Currently Installed Language: en-US

Notice that I have my touchpad enabled in BIOS (my trackpoint has a faulty left button, so I'm waiting
for a replacement and currently need to use the touchpad when there is no external mouse around)

This is the output of xinput list-props when the touchpad is enabled

$ xinput list-props 'SynPS/2 Synaptics TouchPad'

Device 'SynPS/2 Synaptics TouchPad':
 Device Enabled (139): 1
 Coordinate Transf...

[Matt (matt-redhat-bugs)]

Everything is about the same. I have an updated BIOS, but the real question is:
can you replicate my issue. The issue isn't that the touchpad is enabled or disabled. I can't click or use it to scroll at all, aka: disabled.

My issue is that when I out 3 fingers on the touchpad then go click on something. Sometimes it works, sometimes it doesn't, and sometimes it acts as if I just grabbed whatever it is that I clicked on.

I replicate this by clicking on a scroll bar of a browser or a terminal window while I have 3 finger placed on the disabled trackpad.

You may ask: why in the world would someone ever put 3 fingers on a trackpad then try to click? Well, I have larger hands and often times, part of my hand rests on the trackpad and REALLY screws up things.

Please let me know if you can replicate this on your t460p.

$ loginctl
   SESSION UID USER SEAT
        c1 42 gdm seat0
         2 1000 <username> seat0

$ loginctl show-session 2 -p Type
Type=x11

$ uname -a
Linux t460p 4.10.16-200.fc25.x86_64 #1 SMP Mon May 15 15:19:52 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=14 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=15 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad 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)]
    ↳ Video Bus id=8 [slave keyboard (3)]
    ↳ Sleep Button id=9 [slave keyboard (3)]
    ↳ Yubico Yubico Yubikey II id=10 [slave keyboard (3)]
    ↳ Integrated Camera id=11 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
    ↳ ThinkPad Extra Buttons id=16 [slave keyboard (3)]

# dmidecode -t system | head -n 14
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x000C, DMI type 1, 27 bytes
System Information
 Manufacturer: LENOVO
 Product Name: 20FXS0BB0U
 Version: ThinkPad T460p
 Serial Number: PF0N936H
 UUID: AD22BA4C-2708-11B2-A85C-CFCA463AAE82
 Wake-up Type: Power Switch
 SKU Number: LENOVO_MT_20FX_BU_Think_FM_ThinkPad T460p
 Family: ThinkPad T460p

# dmidecode -t bios
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x000B, DMI type 0, 24 bytes
BIOS Information
 Vendor: LENOVO
 Version: R07ET75W (2.15 )
 Release Date: 02/21/2017
 Address: 0xE0000
 Runtime Size: 128 kB
 ROM Size: 16384 kB
 Characteristics:
  PCI is supported
  PNP is supported
  BIOS is upgradeable
  BIOS shadowing is allowed
  Boot from CD is supported
  Selectable boot is supported
  EDD is supported
  3.5"/720 kB floppy services are supported (...

[Vladyslav (vladyslav-redhat-bugs)]

Ok, now I see your problem, To be honest, so far I never
tried to put three fingers on the disabled touchpad and then
issue a click using the trackpoint or an external mouse.

I did it right now and it behaves exactly the way you
wrote: "Sometimes it works, sometimes it doesn't, and sometimes
it acts as if I just grabbed whatever it is that I clicked on."

So yes, I can reproduce this on my T460p.

Now that I payed more attention to it, it appears that when I
use the trackpoint (I'm left-handed), my hand always floats above
the trackpad but never lies directly on it. For the record, I also
have larger hands (but perhaps not as large as yours). I guess this
is the reason why I never encountered this issue. Of course, the
hand position is always a very individual thing, so there are definitely
no "right" or "wrong" ways to use the trackpoint...

In any case, it is weird that that the touchpad input is still somehow
evaluated once it was explicitly disabled. I don't think that this
is how it is supposed to be.

Having said that, I guess part of the issue is that on ThinkPads in general,
the touchpad and the trackpoint are not two separate entities but rather
one piece of hardware. For example, on a T460p the signal from the trackpoint
stick is transferred via the cable that connects the keyboard to the mainboard.
However, the signal from the trackpoint buttons is routed via the same cable
that connects the touchpad to the mobo.

[Peter (peter-redhat-bugs)]

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.

[Matt (matt-redhat-bugs)]

All touchpad options aren't in the control panel anymore. I just have:
General: primary button -> left/right
Mouse: Mouse speed, Natural Scrolling: on/off

xinput test-xi2 produces the same results. I put 3 fingers on the touchpad which doesn't register anything in the logs, but when I go to click the mouse button, sometimes it works, sometimes it doesn't, and sometimes it register the button press but not release.

I'm having a hard time trying to get data when nothing is being registered in any of the logs. It's simply doesn't register any click when I press the mouse button.

[Peter (peter-redhat-bugs)]

you're still using the synaptics driver? if you do an xinput list-props "device name", are the devices prefixed with Synaptics? or still Evdev like in comment #4? If so, you need to switch to the libinput driver. see comment #5. If you have ever had a mate or cinnamon package installed, that could be the reason, they unconditionally overwrite (or used to overwrite) the normal configuration. Look for any symlinks in /etc/X11/xorg.conf.d/

[Matt (matt-redhat-bugs)]

$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=15 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad 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)]
    ↳ Video Bus id=8 [slave keyboard (3)]
    ↳ Sleep Button id=9 [slave keyboard (3)]
    ↳ Yubico Yubico Yubikey II id=10 [slave keyboard (3)]
    ↳ Integrated Camera id=11 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
    ↳ ThinkPad Extra Buttons id=16 [slave keyboard (3)]

$ xinput list-props 'SynPS/2 Synaptics TouchPad'
Device 'SynPS/2 Synaptics TouchPad':
 Device Enabled (139): 0
 Coordinate Transformation Matrix (141): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 libinput Tapping Enabled (274): 0
 libinput Tapping Enabled Default (275): 0
 libinput Tapping Drag Enabled (276): 1
 libinput Tapping Drag Enabled Default (277): 1
 libinput Tapping Drag Lock Enabled (278): 0
 libinput Tapping Drag Lock Enabled Default (279): 0
 libinput Tapping Button Mapping Enabled (280): 1, 0
 libinput Tapping Button Mapping Default (281): 1, 0
 libinput Accel Speed (282): 0.000000
 libinput Accel Speed Default (283): 0.000000
 libinput Natural Scrolling Enabled (284): 0
 libinput Natural Scrolling Enabled Default (285): 0
 libinput Send Events Modes Available (259): 1, 1
 libinput Send Events Mode Enabled (260): 1, 0
 libinput Send Events Mode Enabled Default (261): 0, 0
 libinput Left Handed Enabled (286): 1
 libinput Left Handed Enabled Default (287): 0
 libinput Scroll Methods Available (288): 1, 1, 0
 libinput Scroll Method Enabled (289): 0, 0, 0
 libinput Scroll Method Enabled Default (290): 1, 0, 0
 libinput Click Methods Available (291): 1, 1
 libinput Click Method Enabled (292): 0, 0
 libinput Click Method Enabled Default (293): 1, 0
 libinput Middle Emulation Enabled (294): 0
 libinput Middle Emulation Enabled Default (295): 0
 libinput Disable While Typing Enabled (296): 1
 libinput Disable While Typing Enabled Default (297): 1
 Device Node (262): "/dev/input/event7"
 Device Product ID (263): 2, 7
 libinput Drag Lock Buttons (298): <no items>
 libinput Horizontal Scroll Enabled (299): 1

$ rpm -qa |grep -i mate

$ rpm -qa |grep -i cinnamon

$ ls /etc/X11/xorg.conf.d/
00-keyboard.conf

$ cat /etc/X11/xorg.conf.d/00-keyboard.conf
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "us"
EndSection

[Peter (peter-redhat-bugs)]

well, that's me out of ideas then. libinput driver is being used, I don't know why gnome wouldn't show the touchpad configuration. GNOME *does* disable the touchpad, see libinput Send Events Mode Enabled (260): 1, 0 which indicates that at least mutter is aware of the libinput driver.

With the property set, libinput *should* ignore the touchpad events, I don't know why it doesn't. And we don't have any other debugging tools yet for that specific use-case. Sorry, I really don't know how to debug this further remotely.

[Michael (michael-redhat-bugs)]

I'm also encountering this issue on current F26+Wayland / Thinkpad P50. Appears to happen on all power state changes, cycling the touchpad enable via gnome settings panel/controls temporarily resets the touchpad.

[Fedora (fedora-redhat-bugs)]

libinput-1.8.1-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9877387cfd

[Peter (peter-redhat-bugs)]

*** Bug 1475229 has been marked as a duplicate of this bug. ***

[Fedora (fedora-redhat-bugs)]

libinput-1.8.1-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d3c039ae6b

[Matt (matt-redhat-bugs)]

(In reply to Fedora Update System from comment #24)
> libinput-1.8.1-4.fc26 has been submitted as an update to Fedora 26.
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-9877387cfd

Behavior has not changed with latest libinput:
$ rpm -q libinput
libinput-1.8.1-4.fc26.x86_64

[Brian Murray (brian-murray)]

Ah, it seems to become enabled after resuming from suspend.

[Fedora (fedora-redhat-bugs)]

libinput-1.8.1-4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9877387cfd

[Fedora (fedora-redhat-bugs)]

libinput-1.8.2-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-79e946722c

[Fedora (fedora-redhat-bugs)]

libinput-1.8.2-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-79e946722c

[Fedora (fedora-redhat-bugs)]

libinput-1.8.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb2e09649

[Peter (peter-redhat-bugs)]

Matt - you did reboot after updating? The bug I found and fixed was definitely a libinput bug, so if it's still there there must be something else that I haven't spotted yet.

[Stefan (stefan-redhat-bugs)]

Nice work, thanks! libinput-1.8.2-1.fc26 has fixed the problem on my X1 Carbon. The touchpad stays correctly disabled after opening the lid now.

[Fedora (fedora-redhat-bugs)]

libinput-1.8.2-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb2e09649

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Fedora (fedora-redhat-bugs)]

libinput-1.8.2-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

[Rui (rui-redhat-bugs)]

*** Bug 1490127 has been marked as a duplicate of this bug. ***

[Matt (matt-redhat-bugs)]

(In reply to Peter Hutterer from comment #32)
> Matt - you did reboot after updating? The bug I found and fixed was
> definitely a libinput bug, so if it's still there there must be something
> else that I haven't spotted yet.

My apologies for the late response.

Yes, I have rebooted and there is no change. I also got the latest BIOS update from Lenovo and installed that.

The problem still persists and the mouse still works at the login screen even though it's turned off in the BIOS.

[Daniel van Vugt (vanvugt)]

Slightly related; I find touchpad scrolling doesn't work after resuming from sleep.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[James Henstridge (jamesh)]

So, I don't think there is any problem on the gnome-control-center side: it just sets the org.gnome.desktop.peripherals.touchpad/send-events GSetting key to disabled, and that is persisting over sleeps.

The code in mutter watches this key, and calls MetaInputSettings::set_send_events() on each touchpad device, and ensures it is called on each new input device.

https://git.gnome.org/browse/mutter/tree/src/backends/meta-input-settings.c#n667

In a Wayland session, this calls libinput_device_config_send_events_set_mode():

https://git.gnome.org/browse/mutter/tree/src/backends/native/meta-input-settings-native.c#n36

The touchpad implementation of this is found here:

https://cgit.freedesktop.org/wayland/libinput/tree/src/evdev-mt-touchpad.c#n3089

... which calls tp_suspend:

https://cgit.freedesktop.org/wayland/libinput/tree/src/evdev-mt-touchpad.c#n1670

Which will either leave the touchpad enabled to support soft buttons, or call evdev_device_suspend() otherwise, which closes the underlying device.

Looking in /proc, gnome-shell definitely doesn't have the touchpad evdev device open when I disable the touchpad, but somehow opens it again after resume.

[James Henstridge (jamesh)]

While looking around for code that might resume the touchpad, I noticed that the libinput master code was a bit different to the version we ship: there's a tp_resume_conditional() function that checks sendevents.

And checking the history shows up this patch:

  https://cgit.freedesktop.org/wayland/libinput/commit/src?id=53d53dd18ef14484d632421027cd7b6130013cf0

Fedora is also shipping this as a patch against their libinput-1.8.2 in Fedora 27:

  https://src.fedoraproject.org/rpms/libinput/blob/f27/f/0001-touchpad-don-t-resume-a-disabled-touchpad.patch

[Iain Lane (laney)]

Uploaded the cherry-picked patch

[Launchpad Janitor (janitor)]

This bug was fixed in the package libinput - 1.8.2-1ubuntu2

---------------
libinput (1.8.2-1ubuntu2) artful; urgency=medium

  * debian/patches/0005-touchpad-don-t-resume-a-disabled-touchpad.patch:
    Backport from upstream - keep the disabled state properly across
    suspend/resume. Thanks to Jonas Ådahl for help investigating. (LP:
    #1715479)

 -- Iain Lane <email address hidden> Thu, 28 Sep 2017 18:40:24 +0100

[Fedora (fedora-redhat-bugs)]

libinput-1.8.2-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.