Still present in kernel 4.15.12-301

Still present in kernel 4.15.13-300

Still present in kernel 4.15.14

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.

A workaround is to insert  the `elan_i2c` module manually: `# modprobe elan_i2c`

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.

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.

(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

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

(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! :-)

(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

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?

(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.

(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

*********** 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.

(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.

Thanks for the update.

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.

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.

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.

Still happens on F29 with kernel-4.18.11-300.fc29.x86_64

And still happens on Fedora 28 with kernel 4.18.10-200, too

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.

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).

Still present in all the kernels from the 4.19.5 to 4.19.10 included

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.

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.

Same problem on my X1 Carbon 6th Gen the fix suggested in comment 8 doesn't work for me on Fedora 30 on kernel-5.1.11-300.fc30.x86_64.

On my Thinkpad X1 carbon 6th gen) with 5.1.12-300.fc30.x86_64 the trackpoint buttons stop working after roughly every second suspend. It's probably the same problem as described in this ticket. I will give the suggested workarounds a shot. Will report back if that does not succeed.

A bit broader context, sorry for going off topic: up to last week I used a Thinkpad T450s with Fedora 29 and it was a pretty smooth desktop experience. I am a bit shocked by the number and extent of the various desktop experience quirks I now experience with the X1 Carbon & Fedora 30.

I did a fresh install of fc30 two weeks ago hoping this bug would disappear.  Still happening on 5.1.20-300.fc30.x86_64. Note: The mouse pointer still moves around but I cannot click on anything.  (I wonder if this is a Gnome issue)  

The workaround I found which works 99% of the time:

#!/bin/bash

echo -n "none" > /sys/devices/platform/i8042/serio1/drvctl
echo "Done."

*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

Still happens on F31 with kernel-5.3.0-1.fc31.x86_64

Still happens on Fedora 30, with 5.2.18-200.fc30.x86_64.

What can we do to help to get this fixed? Who are the right people to talk to about that?

I must confirm that this issue is still present on Fedora 30 on x1 carbon 6th gen laptop.
kernel version: 5.3.8-200.fc30.x86_64

After all the dirty fixes I tried I must add that there was not a real fix for this.
So after almost every few suspend, my trackpoint buttons just stop working.

Is there any progress on this issue ?

There was some movement in the rmi4 driver in the 5.5 branch. So I tried 5.5.0-0.rc6.git2.1.fc32.x86_64 from Rawhide on my F31 box and so far I haven't had any problems with the Trackpoint after multiple resumes on my X1C5.
I will continue to monitor whether the issue comes back.

The issue reappeared today. So it may have gotten better (i.e. I now get many more suspend/resume cycles before it occurring) but it is definitely not fixed yet.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This is still an issue in rawhide.
Given that this bug hasn't been fixed in more than three years I am willing to accept that it will probably never be fixed.
Is there a chance we can include the workaround script in the distribution somehow?
Ideally it'd come installed by default as to not break user's machines when resuming from suspend. But I'd be fine to have it as an extra package.