Bug 1567341 - TouchPad off after resume
Summary: TouchPad off after resume
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-desktop
Version: 28
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: KDE SIG
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-04-13 20:07 UTC by Enrique Meléndez
Modified: 2018-12-17 21:29 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-12-17 21:29:48 UTC
Type: Bug

Attachments (Terms of Use)
Xorg.0.log (37.43 KB, text/plain)
2018-04-17 17:50 UTC, Enrique Meléndez
no flags Details

Description Enrique Meléndez 2018-04-13 20:07:50 UTC
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:
1. Suspend
2. Resume

Actual results:
Touchpad off, muse not moving

Expected results:
Touchpad on

Additional info:

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

Comment 1 Enrique Meléndez 2018-04-14 18:53:39 UTC
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

Comment 2 Peter Hutterer 2018-04-17 00:03:57 UTC
Can you attach the full xorg.log please, thanks

Comment 3 Enrique Meléndez 2018-04-17 17:50:24 UTC
Created attachment 1423185 [details]

This is the full Xorg.0.log after suspend/resume

Comment 4 Enrique Meléndez 2018-04-17 17:54:59 UTC
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

Comment 5 Peter Hutterer 2018-04-18 04:36:00 UTC
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.

Comment 6 Enrique Meléndez 2018-04-18 19:46:17 UTC
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:

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

Comment 7 Peter Hutterer 2018-04-19 00:20:36 UTC
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.

Comment 8 Enrique Meléndez 2018-05-16 18:20:29 UTC
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.

Comment 9 Enrique Meléndez 2018-12-17 21:29:48 UTC
The issue went away after installing Fedora 29. Why it happened is anybody's guess.

Note You need to log in before you can comment on or make changes to this bug.