Description of problem:
After suspend/resume, touchpad is off in the Xserver (no mouse movement)
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
Touchpad off, muse not moving
1. After resume, there is no mouse movement nor is there any response from the touchpad buttons (either physical or tap).
2. If the Xserver is killed (ctrl-alt-backspace), the touchpad works again in the Xserver (no need for a reboot)
3. With the touchpad off in the Xserver, i.e. after resume, libinput-debug-events reports touchpad events (this is why I think it is not a kernel issue)
4. libinput is used
Xorg.0.log shows the following after suspend/resume, immediately prior to logging in, with touchpad still off:
[ 6499.338] (II) event4 - SynPS/2 Synaptics TouchPad: device removed
[ 6504.238] (II) event2 - Power Button: device removed
[ 6504.243] (II) event5 - Video Bus: device removed
[ 6504.251] (II) event0 - Power Button: device removed
[ 6504.260] (II) event10 - 2SF001: TOSHIBA Web Camera: device removed
[ 6504.282] (II) event3 - AT Translated Set 2 keyboard: device removed
[ 6504.291] (II) event6 - Toshiba input device: device removed
[ 6504.302] (II) AIGLX: Suspending AIGLX clients for VT switch
After logging in, all eventX are restarted except event4
Additional info that I should have mentioned
Laptop is a Toshiba Satellite R830.
There is no info in /var/log/messages regarding psmouse (except for the touchpad cordinates) or Synaptics/Touchpad
Can you attach the full xorg.log please, thanks
Created attachment 1423185 [details]
This is the full Xorg.0.log after suspend/resume
I am using KDE as desktop. I have enabled the touchpad item in plasma - system tray and set a keyboard shortcut. I can enable/disable the touchpad though this. Now, when I resume the computer after a suspend event, pulling up the touchpad icon makes the touchpad work again; no need to push the enable/disable button. Xorg.0.log shows a new event4 (touchpad) entry
Do an xinput list before/after resume to check if the touchpad is in the device list afterwards. If it is, do a xinput list-props "<device name>" and check the Device Enabled property, is it off? If so, then that explains why it doesn't react in X but works with the libinput tools.
But somehow I strongly suspect a KDE bug. IIRC the server remembers whether the device was disabled before VT switch and restores it thus, but that code hasn't changed in years so this would be the first bug for it.
In the log, the last few lines indicate the touchpad comes back, but it may come back as disabled. Or, more likely, being set to disabled by something in KDE.
xinput reports the touchpad in the device list both before and after suspend/resume of the laptop.
After resume,the touchpad is reported off by xinput:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=11 [slave pointer (2)]
$ xinput list-props 11
Device 'SynPS/2 Synaptics TouchPad':
Device Enabled (142): 0
Any hint as to where to look in KDE?
Ok, there's a 99% chance this is KDE then because if it was the libinput driver I'd get inundated with bug reports about this :)
Punting to plasma-desktop which I think is the right component here.
By sheer luck I found out that if I disable screen locking after resume, the touchpad is not disabled. If I lock the screen and then suspend the laptop, the touchpad is disabled on resume. So, apparently, it is the combination of resume and screen locking that disables it.
The issue went away after installing Fedora 29. Why it happened is anybody's guess.