Bug 1560723 - Elan Trackpoint stop working after suspend (Thinkpad X1 carbon 5th gen)
Summary: Elan Trackpoint stop working after suspend (Thinkpad X1 carbon 5th gen)
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 29
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-26 20:38 UTC by Giuseppe Castagna
Modified: 2019-01-25 15:26 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-07-24 13:51:01 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
felix: needinfo+


Attachments (Terms of Use)

Description Giuseppe Castagna 2018-03-26 20:38:50 UTC
Description of problem:

When I suspend and resume the trackpoint AND the three physical buttons over the trackpad stop working (most of the times but not always). The reason being that the device is unloaded but not reloaded at the resume

Version-Release number of selected component (if applicable):

Linux mango 4.15.10-300.fc27.x86_64 #1 SMP Thu Mar 15 17:13:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

but the problem happened with all 4.15 kernels of Fedora 27

How reproducible:

Suspend and then resume. 


Additional info:

relevant log after resume

Mar 24 14:18:59 mango /usr/libexec/gdm-x-session[1691]: (II) config/udev: removing device TPPS/2 Elan TrackPoint
Mar 24 14:18:59 mango /usr/libexec/gdm-x-session[1691]: (**) Option "fd" "58"
Mar 24 14:18:59 mango /usr/libexec/gdm-x-session[1691]: (II) event15 - TPPS/2 Elan TrackPoint: device removed
Mar 24 14:18:59 mango /usr/libexec/gdm-x-session[1691]: (II) UnloadModule: "libinput"
Mar 24 14:18:59 mango /usr/libexec/gdm-x-session[1691]: (II) systemd-logind: releasing fd for 13:79
Mar 24 14:18:59 mango /usr/libexec/gdm-x-session[1691]: (EE) systemd-logind: failed to release device: Device not taken


a different (now fixed bug) reported that this did not happen with 4.14 kernels
https://bugzilla.redhat.com/show_bug.cgi?id=1554933
more precisely that the module was unloaded and then reloaded.
I cannot confirm that since I just installed F27 on my X1


For some reasons I do not understand this behavior is not constant. In some cases the module is not unloaded at the resume and therefore the trackpoint keeps working

Comment 1 Giuseppe Castagna 2018-03-30 14:28:33 UTC
Still present in kernel 4.15.12-301

Comment 2 Giuseppe Castagna 2018-03-31 11:56:19 UTC
Still present in kernel 4.15.13-300

Comment 3 Giuseppe Castagna 2018-04-06 06:58:01 UTC
Still present in kernel 4.15.14

Comment 4 klingt.net 2018-04-09 08:06:28 UTC
I can confirm this issue for my Thinkpad X1C5 running Arch Linux kernel 4.15.15 but the problem was present in all previous 4.15 versions as well.

Comment 5 klingt.net 2018-04-09 10:52:46 UTC
A workaround is to insert  the `elan_i2c` module manually: `# modprobe elan_i2c`

Comment 6 Giuseppe Castagna 2018-04-09 14:19:06 UTC
Thank you for the workaround. Unfortunately it does not work on Fedora. Even though the module is correctly inserted:


[root@mango beppe]# modprobe -r -vv elan_i2c
modprobe: INFO: custom logging function 0x55ac21078de0 registered
rmmod elan_i2c
modprobe: INFO: context 0x55ac21e2a540 released
[root@mango beppe]# lsmod | grep elan
[root@mango beppe]# modprobe -vv elan_i2c
modprobe: INFO: custom logging function 0x56016ebb7de0 registered
insmod /lib/modules/4.15.14-300.fc27.x86_64/kernel/drivers/input/mouse/elan_i2c.ko.xz 
modprobe: INFO: context 0x56016fad3540 released
[root@mango beppe]# lsmod | grep elan
elan_i2c               40960  0


the trackpoint does not work. Only a reboot fixes it for the time being.

Comment 7 Giuseppe Castagna 2018-04-15 10:08:05 UTC
Still present in 4.15.15. Carrying on on the previous comment, it cannot be the elan_i2c module, since it is not loaded when the trackpoint works. I tried to make a diff of the results of lsmod when the trackpoint works and when it doesn't and they are identical. Therefore the problem comes from a module compiled in the kernel.

Comment 8 andy 2018-04-18 12:37:33 UTC
(In reply to Giuseppe Castagna from comment #7)
> Still present in 4.15.15. Carrying on on the previous comment, it cannot be
> the elan_i2c module, since it is not loaded when the trackpoint works. I
> tried to make a diff of the results of lsmod when the trackpoint works and
> when it doesn't and they are identical. Therefore the problem comes from a
> module compiled in the kernel.

I managed to make a workaround for this issue on my X1C6.

1. sudo <favorite editor> /lib/systemd/system-sleep/trackpad

2. paste contents below in the file and save it

#!/bin/sh
if [ "${1}" == "post" ]; then
  echo -n none > /sys/devices/platform/i8042/serio1/drvctl
  sleep 1
  echo -n reconnect > /sys/devices/platform/i8042/serio1/drvctl
fi

3. set executable flag on file /lib/systemd/system-sleep/trackpad
sudo chmod 755 /lib/systemd/system-sleep/trackpad

4. reboot

/ andy

Comment 9 Giuseppe Castagna 2018-04-19 12:02:30 UTC
Thank you Andy, your fix works perfectly. I just added this line before reconnect:

  printf "Apply patch to reload Elantech TrackPoint after suspend" | systemd-cat -t "/lib/systemd/system-sleep/trackpad"


So as to record the application of the fix in the system journal. 

Indeed now after resume the trackpoint is removed

Apr 19 13:44:56 mango kernel: PM: suspend entry (deep)
Apr 19 13:44:56 mango kernel: PM: Syncing filesystems ... done.
Apr 19 13:48:09 mango kernel: Freezing user space processes ... (elapsed 0.002 seconds) done.
Apr 19 13:48:09 mango kernel: OOM killer disabled.
Apr 19 13:48:09 mango kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Apr 19 13:48:09 mango kernel: Suspending console(s) (use no_console_suspend to debug)
...
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (II) config/udev: removing device TPPS/2 Elan TrackPoint
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (**) Option "fd" "54"
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (II) event15 - TPPS/2 Elan TrackPoint: device removed
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (II) UnloadModule: "libinput"
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (II) systemd-logind: releasing fd for 13:79
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (EE) systemd-logind: failed to release device: Device not taken
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (II) config/udev: removing device Synaptics TM3288-003
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (**) Option "fd" "53"
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (II) event5  - Synaptics TM3288-003: device removed
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (II) UnloadModule: "libinput"
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (II) systemd-logind: releasing fd for 13:69
Apr 19 13:48:10 mango /usr/libexec/gdm-x-session[1929]: (EE) systemd-logind: failed to release device: Device not taken


Then the script is executed:

Apr 19 13:48:11 mango /lib/systemd/system-sleep/trackpad[14329]: Apply patch to reload Elantech TrackPoint after suspend

and after some unsucessful tries it is reloaded

Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) config/udev: Adding input device Synaptics TM3288-003 (/dev/input/mouse0)
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) No input driver specified, ignoring this device.
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) This device may have been added with another device file.
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) config/udev: Adding input device Synaptics TM3288-003 (/dev/input/event5)
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Synaptics TM3288-003: Applying InputClass "evdev touchpad catchall"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Synaptics TM3288-003: Applying InputClass "libinput touchpad catchall"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) Using input driver 'libinput' for 'Synaptics TM3288-003'
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) systemd-logind: got fd for /dev/input/event5 13:69 fd 53 paused 0
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Synaptics TM3288-003: always reports core events
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Option "Device" "/dev/input/event5"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Option "_source" "server/udev"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event5  - Synaptics TM3288-003: is tagged by udev as: Touchpad
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event5  - Synaptics TM3288-003: device is a touchpad
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event5  - Synaptics TM3288-003: device removed
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Option "config_info" "udev:/sys/devices/rmi4-06/input/input46/event5"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) XINPUT: Adding extended input device "Synaptics TM3288-003" (type: TOUCHPAD, id 12)
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Option "AccelerationScheme" "none"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Synaptics TM3288-003: (accel) selected scheme none/0
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Synaptics TM3288-003: (accel) acceleration factor: 2.000
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Synaptics TM3288-003: (accel) acceleration threshold: 4
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event5  - Synaptics TM3288-003: is tagged by udev as: Touchpad
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event5  - Synaptics TM3288-003: device is a touchpad
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) config/udev: Adding input device TPPS/2 Elan TrackPoint (/dev/input/mouse1)
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) No input driver specified, ignoring this device.
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) This device may have been added with another device file.
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) config/udev: Adding input device TPPS/2 Elan TrackPoint (/dev/input/event15)
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) TPPS/2 Elan TrackPoint: Applying InputClass "evdev pointer catchall"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) TPPS/2 Elan TrackPoint: Applying InputClass "libinput pointer catchall"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) Using input driver 'libinput' for 'TPPS/2 Elan TrackPoint'
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) systemd-logind: got fd for /dev/input/event15 13:79 fd 54 paused 0
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) TPPS/2 Elan TrackPoint: always reports core events
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Option "Device" "/dev/input/event15"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Option "_source" "server/udev"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event15 - TPPS/2 Elan TrackPoint: is tagged by udev as: Mouse Pointingstick
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event15 - TPPS/2 Elan TrackPoint: trackpoint device set to range 20
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event15 - TPPS/2 Elan TrackPoint: device is a pointer
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event15 - TPPS/2 Elan TrackPoint: device removed
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Option "config_info" "udev:/sys/devices/rmi4-06/rmi4-06.fn03/serio9/input/input47/event15"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) XINPUT: Adding extended input device "TPPS/2 Elan TrackPoint" (type: MOUSE, id 13)
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) Option "AccelerationScheme" "none"
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) TPPS/2 Elan TrackPoint: (accel) selected scheme none/0
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) TPPS/2 Elan TrackPoint: (accel) acceleration factor: 2.000
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (**) TPPS/2 Elan TrackPoint: (accel) acceleration threshold: 4
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event15 - TPPS/2 Elan TrackPoint: is tagged by udev as: Mouse Pointingstick
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event15 - TPPS/2 Elan TrackPoint: trackpoint device set to range 20
Apr 19 13:48:12 mango /usr/libexec/gdm-x-session[1929]: (II) event15 - TPPS/2 Elan TrackPoint: device is a pointer


hope it helps

Comment 10 andy 2018-04-19 12:04:50 UTC
(In reply to Giuseppe Castagna from comment #9)
> Thank you Andy, your fix works perfectly. I just added this line before
> reconnect:
> 
> *snippet*
> 
> hope it helps

I'm glad that it worked for you too! :-)

Comment 11 Felix Kaechele 2018-04-29 06:46:57 UTC
(In reply to andy from comment #8)

> I managed to make a workaround for this issue on my X1C6.

This workaround works for me as well.

The issue is still present on Fedora 28 and kernel-4.16.4-300.fc28.x86_64

Comment 12 Giuseppe Castagna 2018-05-13 16:57:00 UTC
Also present in Fedora 28 kernel  4.16.7-300. 

Actually, I just installed Fedora 28 and the situation on the trackpad side become worse since the trackpad right click (lower right corner of the trackpad) no longer works. Did anybody else see this regression?

Comment 13 andy 2018-05-13 16:58:44 UTC
(In reply to Giuseppe Castagna from comment #12)
> Also present in Fedora 28 kernel  4.16.7-300. 
> 
> Actually, I just installed Fedora 28 and the situation on the trackpad side
> become worse since the trackpad right click (lower right corner of the
> trackpad) no longer works. Did anybody else see this regression?

See https://fedoraproject.org/wiki/Common_F28_bugs#gnome-clickfinger-change for the right click issue.

Comment 14 Giuseppe Castagna 2018-05-13 17:26:56 UTC
(In reply to andy from comment #13)
> (In reply to Giuseppe Castagna from comment #12)
> > Also present in Fedora 28 kernel  4.16.7-300. 
> > 
> > Actually, I just installed Fedora 28 and the situation on the trackpad side
> > become worse since the trackpad right click (lower right corner of the
> > trackpad) no longer works. Did anybody else see this regression?
> 
> See https://fedoraproject.org/wiki/Common_F28_bugs#gnome-clickfinger-change
> for the right click issue.

Thanks Andy, I had just found it in the Gnome Tweaks and was going to answer myself, but you were faster

Comment 15 Justin M. Forbes 2018-07-23 15:08:08 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs.

Fedora 28 has now been rebased to 4.17.7-200.fc28.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 16 andy 2018-07-24 06:18:01 UTC
(In reply to Justin M. Forbes from comment #15)
> *********** MASS BUG UPDATE **************
> 
> We apologize for the inconvenience.  There are a large number of bugs to go
> through and several of them have gone stale.  Due to this, we are doing a
> mass bug update across all of the Fedora 28 kernel bugs.
> 
> Fedora 28 has now been rebased to 4.17.7-200.fc28.  Please test this kernel
> update (or newer) and let us know if you issue has been resolved or if it is
> still present with the newer kernel.
> 
> If you experience different issues, please open a new bug report for those.

I can confirm that the issue is gone with this kernel and I am not using any workarounds. This using a Thinkpad X1 Gen 6.

Comment 17 Justin M. Forbes 2018-07-24 13:51:01 UTC
Thanks for the update.

Comment 18 Giuseppe Castagna 2018-07-24 15:33:34 UTC
Please reopen. It is not fixed for me. I use a Thinkpad X1 Gen 5. 

- Installed 4.17.7-200.fc28 reboot

- removed patch

- problems reappear (tried 3 reboots)

- applying the patch makes the problem go away again.

Comment 19 andy 2018-09-10 14:49:13 UTC
Ok. This problem is still present. My apologies Giuseppe. 

Now that Thinkpad X1 Gen6 have native S3 sleep we can see that some devices (especially NFC ones) have problem with the trackpad after resuming from sleep. I am not sure that this is related to the problem above. 

See for example: 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427
https://forums.lenovo.com/t5/Linux-Discussion/X1-Carbon-Gen-6-cannot-enter-deep-sleep-S3-state-aka-Suspend-to/m-p/4200223/highlight/true#M11685

The workaround for this is to adjust powersaving settings with TLP with these parameters:
USB_AUTOSUSPEND_DISABLE_ON_SHUTDOWN=1
USB_AUTOSUSPEND=0
RUNTIME_PM_BLACKLIST="00:1f.4"

And have a script to reinitialize the trackpad in /usr/lib/systemd/system-sleep:
if [ "${1}" == "post" ]; then
  echo -n none > /sys/devices/platform/i8042/serio1/drvctl
  sleep 1
  echo -n reconnect > /sys/devices/platform/i8042/serio1/drvctl
fi

I don't know if we shall continue in this bug report or create a new but these are the essential details to get it working again.

Comment 20 Laura Abbott 2018-10-01 21:33:08 UTC
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs.
 
Fedora 28 has now been rebased to 4.18.10-300.fc28.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29.
 
If you experience different issues, please open a new bug report for those.

Comment 21 Felix Kaechele 2018-10-02 18:45:23 UTC
Still happens on F29 with kernel-4.18.11-300.fc29.x86_64

Comment 22 Giuseppe Castagna 2018-10-03 13:37:21 UTC
And still happens on Fedora 28 with kernel 4.18.10-200, too

Comment 23 Jeremy Cline 2018-12-03 17:33:35 UTC
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs.
 
Fedora 29 has now been rebased to 4.19.5-300.fc29.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you experience different issues, please open a new bug report for those.

Comment 24 Giuseppe Castagna 2018-12-05 13:22:16 UTC
I tested both with 4.19.5-300.fc29 and 4.19.4-300.fc29. The situation now (4.19) is better though the problem is not solved. There is a clear improvement over the 4.18 kernels since now the Trackpoint does not stop working systematically at every suspend as it was with the 4.18, but just sporadically. This also means that when the trackpoint does not resume, it usually suffices to suspend a couple of time more to have the trackpoint operational again. Also, I noticed a slight improvement 
 of the 4.19.5 over the 4.19.4 with respect to the frequency by which this happens. That said, the problem is not completely solved since it still happens (let's say about once every five suspensions ... just my gross impression, no exact measure).

Comment 25 Giuseppe Castagna 2019-01-06 13:59:17 UTC
Still present in all the kernels from the 4.19.5 to 4.19.10 included

Comment 26 Niek Beernink 2019-01-08 09:06:44 UTC
I have the same problem on kernel-4.19.13-300.fc29.x86_64. I can confirm what Giuseppe wrote; The workaround usually works but sometimes it doesn't, requiring a full shutdown & startup of the X1 Carbon to fix the broken track point and/or trackpad.

Comment 27 Giuseppe Castagna 2019-01-25 15:26:15 UTC
Just for those that had not time to read the whole thread, though the workaround of suspending several times may fail, the fix suggested in comment 8 (and, if you wish, the modification in comment 9 as well) works flawlessly, at least for me.


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