Bug 33292 - [psmouse] Trackpoint takes long time to get detected
Summary: [psmouse] Trackpoint takes long time to get detected
Status: REOPENED
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-14 23:20 UTC by Matthew Gyurgyik
Modified: 2024-05-31 14:35 UTC (History)
29 users (show)

See Also:
Kernel Version: 3.7
Subsystem:
Regression: No
Bisected commit-id:


Attachments
ls -l /dev/input (3.52 KB, text/plain)
2011-04-14 23:20 UTC, Matthew Gyurgyik
Details
dmesg - trackpoint works (39.86 KB, text/plain)
2011-04-14 23:21 UTC, Matthew Gyurgyik
Details
dmesg - no trackpoint (36.72 KB, text/plain)
2011-04-14 23:22 UTC, Matthew Gyurgyik
Details
kernel.log (172.59 KB, text/x-log)
2011-04-18 11:05 UTC, Matthew Gyurgyik
Details
i8042.debug output from modprobing psmouse until i8042 settles (43.82 KB, text/plain)
2012-11-07 09:00 UTC, Chow Loong Jin
Details
i8042.debug output between attempting to move the undetected trackpoint and i8042 settling again (394.07 KB, text/plain)
2012-11-07 09:01 UTC, Chow Loong Jin
Details
try to deactivate/activeate mouse again if it failed. (1.04 KB, patch)
2017-06-29 04:28 UTC, Zhenjie Wang
Details | Diff

Description Matthew Gyurgyik 2011-04-14 23:20:20 UTC
Created attachment 54402 [details]
ls -l /dev/input

Hello.

I got a new Thinkpad E420s the otherday and have come across a odd problem. 

This laptop has a touchpad and a trackpoint. Sometimes the trackpoint will be detected and sometimes it will not.

Distro: Arch Linux

When the trackpoint is detected:
*rmmod psmouse results in mouse0 and mouse2 disappearing (ls /dev/input). mouse1 = usb logitech mouse
*modprobe psmouse results in mouse0 (the trackpoint) being detected and created right away. However, it takes about 20 seconds for the trackpoint (mouse2) to be created.

When the trackpoint is NOT detected I simply have mouse0 (touchpad) and mouse1 (usb logitech mouse)

Work / Solution
*Reboot into Windows 7. Insure trackpoint works (always does). Reboot into Linux device is detected. In my tests it seems that the device stops getting detected after 6-8 reboots. However, I did also have the problem after resuming from suspend-to-ram.

Let me know what information I need to provide and any way that I can help.
Comment 1 Matthew Gyurgyik 2011-04-14 23:21:51 UTC
Created attachment 54412 [details]
dmesg - trackpoint works
Comment 2 Matthew Gyurgyik 2011-04-14 23:22:19 UTC
Created attachment 54422 [details]
dmesg - no trackpoint
Comment 3 Matthew Gyurgyik 2011-04-16 20:32:37 UTC
It seems that the trackpoint will get detected after a while. I noticed that the trackpoint was detected and started to work after 40 minutes uptime.
Comment 4 Matthew Gyurgyik 2011-04-18 11:03:31 UTC
Apr 18 06:39:40 skynet kernel: [    7.220899] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6
Apr 18 06:39:40 skynet kernel: [    7.768977] input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/input/input7
Apr 18 06:39:40 skynet kernel: [    7.769205] generic-usb 0003:046D:C03D.0001: input,hidraw0: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.0-1.2/input0
Apr 18 06:39:40 skynet kernel: [    7.801948] input: Integrated Camera as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input8
Apr 18 06:59:27 skynet kernel: [ 1197.429868] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/serio2/input/input9

As you can see it took about 20 minutes to detect the trackpoint ("PS/2 generic Mouse")

I will attach the kernel.log file.

Running: 2.6.38.3
Comment 5 Matthew Gyurgyik 2011-04-18 11:05:23 UTC
Created attachment 54592 [details]
kernel.log

As you can see, the trackpoint was detected about 20 minutes after the touchpad.
Comment 6 Manoj Iyer 2011-04-18 15:45:46 UTC
I have a similar problem with the X220, from what I found was, if you disable the touchpad in the bios, the trackpoint will work flawlessly. It will be recognized as a IBM Trackpoint device. If you enable the touchpad, the trackpoint is setup as a pass-through device and psmouse_probe() fails to get a valid ID from the controller. Digging deeper it seems like the controller is NAKing ID requests. Could this be a firmware/bios issue?
Comment 7 Keng-Yü Lin 2011-04-20 14:33:33 UTC
It is found that limiting the ps/2 protocol use to bare (modprobe psmouse proto=bare) makes both the trackpoint and touchpad work on X220. Does this also fix Thinkpad E420s, too?
Comment 8 Matthew Gyurgyik 2011-04-21 14:24:12 UTC
As far as I can tell this seems to fix the problem! However, it is still listed as a "PS/2 Generic Mouse" which isn't a big issue.

Is it possible to have psmouse load with proto=bare for this mouse/touchpad? How would something like this be done in the kernel/module (curious)?
Comment 9 Matthew Gyurgyik 2011-04-21 14:36:53 UTC
Just discovered it works, BUT I lose the ability to scroll and do the two finger tap, middle click using the clickpad/touchpad.
Comment 10 Allan Sandfeld 2011-05-02 10:09:23 UTC
The trackpoint is detected when the psmouse.c driver realizes it has lost synchronization. So it is probably misdetecting and trying to parse a different protocol. Which also explains why parsing proto=bare works.

The question is now: Why is there a difference in functionality when proto=bare is used and when psmouse degrades the protocol by itself.
Comment 11 Casey Harkins 2011-05-19 00:56:15 UTC
What information is needed from us experiencing the bug to try and address this? Do we need i8042.debug from the time we boot until the time the trackpoint is detected?
Comment 12 Chow Loong Jin 2011-06-23 13:37:02 UTC
When using proto=bare, only one input device appears to be detected by psmouse, and both trackpoint and touchpad operate through that device. On the other hand, this device isn't detected to be a touchpad, so the evdev Xorg driver is used instead of the synaptics driver. That's why tapping, and every other touchpad-specific feature does not work.
Comment 13 Alan 2012-08-20 15:48:53 UTC
If this is still seen please re-open/update the bug and also post a summary to linux-input@vger.kernel.org - thanks
Comment 14 Jonas Jensen 2012-10-21 07:25:34 UTC
This bug is still present in kernel 3.6.2 on my Thinkpad L430.
Comment 15 Søren Nørgaard 2012-10-22 19:13:42 UTC
Likewise, still a problem in kernel 3.6.2-1 on Lenovo Thinkpad L530. Using `psmouse proto=impr` makes the trackpoint usable, but disables multitouch functionality.
Comment 16 Chris Tolliday 2012-11-06 23:33:07 UTC
Still having this problem too, kernel 3.6.2 on Thinkpad E420s
Comment 17 Chow Loong Jin 2012-11-07 08:58:52 UTC
I posted this on linux-input sometime back, but either forgot to attach the log files, or they got stripped: http://thread.gmane.org/gmane.linux.kernel.input/21804

I'll attach the log files here instead.
Comment 18 Chow Loong Jin 2012-11-07 09:00:09 UTC
Created attachment 85741 [details]
i8042.debug output from modprobing psmouse until i8042 settles
Comment 19 Chow Loong Jin 2012-11-07 09:01:56 UTC
Created attachment 85751 [details]
i8042.debug output between attempting to move the undetected trackpoint and i8042 settling again
Comment 20 Keith Lawson 2012-11-07 20:57:12 UTC
I'm also having this problem on a Lenovo L430 but logged it against bug #48161.
Comment 21 Jukka Helinko 2012-11-08 11:01:25 UTC
At least the case with the Lenovo L430 touchpad & trackpoint is that when the device is detected as ETPS/2 Elantech Touchpad touching the trackpoint sends a series of bytes which confuses the elantech driver. And leads to lost sync at byte 6 / driver resynced messages.

If imps protocol is forced, both trackpoint and touchpad work fine, but advanced configuration possibilities are lost. 

What I've figured out so far is that in the Elantech/synaptics mode the trackpoint sends 6 byte PS/2ish data:
0x30 0x00 0x00 0x06 0xf5 0xfc
0x30 0x00 0x00 0x06 0xfa 0xfd
0x30 0x00 0x00 0x06 0xfb 0xfe
0x30 0x00 0x00 0x06 0xfb 0xfd
0x30 0x00 0x00 0x06 0xfb 0xfe
0x30 0x00 0x00 0x06 0xf5 0xfb
0x30 0x00 0x00 0x06 0xf9 0xfe
0x30 0x00 0x00 0x06 0xf5 0xfb
0x30 0x00 0x00 0x06 0xfa 0xfd
0x30 0x00 0x00 0x06 0xf5 0xfb
0x30 0x00 0x00 0x06 0xfa 0xfd

Which should be parsed separately by the Elantech driver or some other driver? 
Any way the format seems to be something like this
1st byte: [possibly Y overflow?, possibly X overflow?, Y sign, X sign, ??, Middle Btn, Right Btn, Left Btn]
2nd byte: No idea, most of the time either 0x00 or 0x80
3rd byte: No idea, most of the time either 0x00 or 0x80
4th byte: No idea about the 1st half, lower half is 0x6 for trackpoint events
5th byte: Rest of the X movement
6th byte: Rest of the Y movement

With this I at least was able to hack the elantech driver so that the trackpoint and touchpad are usable, however the problem (besides the unknown data) is that I have no idea how to detect if the device has a trackpoint, so can't really create a patch that would be suitable for other configurations.
Comment 22 Chung-yih Wang 2012-11-08 14:22:32 UTC
I have no idea about the elantech+synaptics combination. However, I had a patch(https://lkml.org/lkml/2012/10/31/211) which was to solve the detection of synaptics trackpoint issue mentioned above. Please give it a try and any feedback will be appreciated.
Comment 23 Keith Lawson 2012-11-09 00:01:56 UTC
(In reply to comment #22)
> I have no idea about the elantech+synaptics combination. However, I had a
> patch(https://lkml.org/lkml/2012/10/31/211) which was to solve the detection
> of
> synaptics trackpoint issue mentioned above. Please give it a try and any
> feedback will be appreciated.

This patch didn't change the behavior on an L430 for me but it's an Elantech trackpad. Still see the following in my message log: 


Nov  8 23:55:52 l430kl kernel: [  950.573824] psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x350f02)
Nov  8 23:55:52 l430kl kernel: [  950.587737] psmouse serio1: elantech: Synaptics capabilities query result 0xb9, 0x15, 0x0c.
Nov  8 23:55:53 l430kl kernel: [  950.657384] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input14
Nov  8 23:56:01 l430kl kernel: [  959.193698] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
Nov  8 23:56:01 l430kl kernel: [  959.279526] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
Nov  8 23:56:01 l430kl kernel: [  959.294517] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
Nov  8 23:56:01 l430kl kernel: [  959.309014] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
Nov  8 23:56:01 l430kl kernel: [  959.323015] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
Nov  8 23:56:01 l430kl kernel: [  959.323024] psmouse serio1: issuing reconnect request

The timeouts are generated as soon as I touch the trackpoint which doesn't function.
Comment 24 Chris Tolliday 2013-02-10 09:17:35 UTC
Still seeing this problem on my thinkpad e420s, the exact behaviour for me is this:
after sleep/wake or start up the touchpad takes a few seconds to be detected, after that I click a trackpoint button, the touchpad stops working for a few seconds, when it starts working again one of two things happens:
1. the trackpoint and buttons start working again, along with the touchpad
2. the touchpad is working but continuing to press the buttons or trackpoint does nothing

it seems completely random which of the above happens, if 2 happens I have to call rmmod psmouse && modprobe psmouse to restart the above, has same effect as sleep/wake. The amount of time it waits varies as well.

this is the output from scenario 1, good:
[57553.675253] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0
[57553.759237] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input19
[57563.997514] psmouse serio6: (null) at synaptics-pt/serio0/input0 lost synchronization, throwing 1 bytes away.
[57565.808609] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/serio6/input/input20

and 2, bad:
[57533.017205] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0
[57533.105277] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input18
[57553.675233] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.0, id: 0x1e2b1, caps: 0xd001a3/0x940300/0x120c00, board id: 1719, fw id: 727581

This is on 3.7.6
Comment 25 Arnaud Vandyck 2016-04-13 11:52:02 UTC
Fujitsu Lifebook E754, Debian testing, Linux 4.4.6-1 (2016-03-17) x86_64 GNU/Linux

...
[   11.040041] psmouse serio5: (null) at synaptics-pt/serio0/input0 lost synchronization, throwing 2 bytes away.
[   12.633371] input: PS/2 Generic Mouse as /devices/platform/i8042/serio2/serio5/input/input9
[   12.782945] psmouse serio2: TouchPad at isa0060/serio2/input0 lost sync at byte 1
[   12.783532] psmouse serio2: TouchPad at isa0060/serio2/input0 lost sync at byte 1
[   12.784136] psmouse serio2: TouchPad at isa0060/serio2/input0 lost sync at byte 1
[   12.784761] psmouse serio2: TouchPad at isa0060/serio2/input0 lost sync at byte 1
[   12.785281] psmouse serio2: TouchPad at isa0060/serio2/input0 lost sync at byte 1
[   12.785285] psmouse serio2: issuing reconnect request
...
Comment 26 Zhenjie Wang 2017-06-29 04:28:31 UTC
Created attachment 257213 [details]
try to deactivate/activeate mouse again if it failed.

Trackpoint is disconnected caused by failing to deactivate parent mouse ( synaptics in T460p).

Many functions deactivate parent mouse without checking the return value.
So try to deactivate mouse again when it failed.
It works.
Comment 27 Zhenjie Wang 2017-06-29 04:39:16 UTC
Comment on attachment 257213 [details]
try to deactivate/activeate mouse again if it failed.

>diff --git a/drivers/input/mouse/psmouse-base.c
>b/drivers/input/mouse/psmouse-base.c
>index a598b72..ebec46d 100644
>--- a/drivers/input/mouse/psmouse-base.c
>+++ b/drivers/input/mouse/psmouse-base.c
>@@ -1255,7 +1255,10 @@ static void psmouse_initialize(struct psmouse *psmouse)
>  */
> int psmouse_activate(struct psmouse *psmouse)
> {
>-      if (ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_ENABLE)) {
>+      int tries = 0;
>+      while (tries++ < 5 && ps2_command(&psmouse->ps2dev, NULL,
>PSMOUSE_CMD_ENABLE))
>+              ;
>+      if (tries > 5) {
>               psmouse_warn(psmouse, "Failed to enable mouse on %s\n",
>                            psmouse->ps2dev.serio->phys);
>               return -1;
>@@ -1271,7 +1274,10 @@ int psmouse_activate(struct psmouse *psmouse)
>  */
> int psmouse_deactivate(struct psmouse *psmouse)
> {
>-      if (ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_DISABLE)) {
>+      int tries = 0;
>+      while (tries++ < 5 && ps2_command(&psmouse->ps2dev, NULL,
>PSMOUSE_CMD_DISABLE))
>+              ;
>+      if (tries > 5) {
>               psmouse_warn(psmouse, "Failed to deactivate mouse on %s\n",
>                            psmouse->ps2dev.serio->phys);
>               return -1;
Comment 28 Simon 2020-01-12 11:26:26 UTC
I have this problem too. Thinkpad x250. Kernel 5.0.0-37-generic. 

Trackpoint is not working at all.
Comment 29 Will Carroll 2020-04-26 01:28:35 UTC
I have this issue as well on a Thinkpad T480 with kernel 5.4.0.

dmesg says:
[  797.604357] psmouse serio2: TrackPoint at rmi4-00.fn03/serio0/input0 lost synchronization, throwing 1 bytes away.
[  797.638878] psmouse serio2: resync failed, issuing reconnect request
[  942.235769] psmouse serio2: TrackPoint at rmi4-00.fn03/serio0/input0 lost synchronization, throwing 1 bytes away.
[  967.658977] psmouse serio2: TrackPoint at rmi4-00.fn03/serio0/input0 lost synchronization, throwing 1 bytes away.
[ 1131.429133] psmouse serio2: TrackPoint at rmi4-00.fn03/serio0/input0 lost synchronization, throwing 1 bytes away.

This happens intermittently, sometimes the driver is able to reconnect, other times not.
Comment 30 mps 2021-08-01 04:46:36 UTC
Have the same problem as Will with my T480 on kernel 5.4.0-80-generic (Ubuntu 20.04.2 LTS).

One can bring it back for a couple of minutes with the following:
sudo rmmod -f psmouse
sudo modprobe -v psmouse resync_time=5 resetafter=5

Also have a look at
xinput --list
to see if it both devices (synaptics and trackpoint) came back.

However, the same dmesg error pops up after some minutes...
Comment 31 Will Carroll 2021-08-01 11:32:41 UTC
I'm now running kernel 5.10 on Debian. I finally got tired of it enough a few months ago and replaced the keyboard and all of my issues resolved. There are enough people reporting the problem here that it may seem this is a common failure mode for this keyboard.
Comment 32 EL Lobo Negron 2021-10-15 22:29:46 UTC
I can atest that as of today 10/15/2021 this bug is indeed present. I'm using OpenSUSE Tumbleweed with kernel "5.14.9-1-default"  this annoying bug for me started arround 2 months ago and it is still present. At first i thought it was some weird hardware failure but i checked on my dmesg and i see the following; 

[  115.626674] psmouse serio3: TrackPoint at rmi4-00.fn03/serio0/input0 lost synchronization, throwing 1 bytes away.
[  152.287129] psmouse serio3: TrackPoint at rmi4-00.fn03/serio0/input0 lost synchronization, throwing 1 bytes away.
[  221.063952] psmouse serio3: TrackPoint at rmi4-00.fn03/serio0/input0 lost synchronization, throwing 1 bytes away.
[  649.792306] BTRFS info (device dm-2): qgroup scan completed (inconsistency flag cleared)
[  737.574400] psmouse serio3: TrackPoint at rmi4-00.fn03/serio0/input0 lost synchronization, throwing 1 bytes away.

PS: Upon rebooting, at the login screen in sddm i can actually use the trackpoint and its buttons but shoftly after 3-5 seconds i cant use it anymore
Comment 33 mps 2021-10-15 22:50:53 UTC
Though Windows (and some Kernel version on Arch) did not present that issue,
I got tired and replaced the keyboard FRU 01HX379 with FRU 01HX459 -- good so far.
Comment 34 Nannk 2022-10-18 20:43:04 UTC
Have a similar problem on t480 on kernel 6.0.2-arch1-1. The trackpoint works at first, then the input starts to get "mushy", then (after about 3 minutes of constant use) trackpoint freaks out (cursor teleports across the screen, random rmb/lmb/mmb presses). Disabling/Enabling both trackpad/trackpoint in bios has no effect on xinput cli output.
Trackpoint is recognised as "PS/2 Generic Mouse".
Comment 35 Rtmigo 2023-05-11 01:17:55 UTC
Having similar issue as https://bugzilla.kernel.org/show_bug.cgi?id=33292#c34:

It's a T560. The TrackPoint is detected as "PS/2 Generic Mouse". BIOS Enable/Disable have no effect on the TrackPoint.

I am able to use it for 10-20 seconds, then it makes random movements and clicks, and then freezes. After that cursor can still be moved by touchpad, but not the trackpoint.

Tested with:
- Mint Cinnamon, X11, kernel 6.4rc1
- Fedora 38, Wayland, kernel 6.2

In Windows the same TrackPoint seems to be OK, at least on my USB-bootable Windows.

It is important to clarify that this is a replacement keyboard purchased from Aliexpress. The original keyboard had no such problems.

If even BIOS cannot disable this "TrackPoint", maybe the problem is not actually about the original trackpoints, but some non-genuine devices sold as replacements.
Comment 36 Przemek 2023-10-27 16:31:00 UTC
Similar problem here. Machine is the t440p with changed touchpad from t450 (it fits and was working fine), some logs:

[    7.853125] rmi4_smbus 9-002c: registering SMbus-connected sensor
[    7.904417] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM3053-008, fw id: 2491654
[    7.960935] input: Synaptics TM3053-008 as /devices/pci0000:00/0000:00:1f.3/i2c-9/9-002c/rmi4-00/input/input20
[    7.966394] serio: RMI4 PS/2 pass-through port at rmi4-00.fn03
[    8.373257] input: TPPS/2 IBM TrackPoint as /devices/pci0000:00/0000:00:1f.3/i2c-9/9-002c/rmi4-00/rmi4-00.fn03/serio3/input/input21
[81220.734879] psmouse serio3: TrackPoint at rmi4-00.fn03/serio0/input0 lost synchronization, throwing 1 bytes away.

Gentoo/ SuSe Tumbleweed.
After resume from suspend trackpoint and touchpad doesn't work anymore.
Comment 37 Przemek 2023-10-28 13:15:05 UTC
Issue happen again: here is the log excerpt:
[    1.114640] psmouse serio1: synaptics: queried max coordinates: x [..5676], y [..4758]
[    1.227504] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1096..]
[    1.227508] psmouse serio1: synaptics: Trying to set up SMBus access
[    1.230179] psmouse serio1: synaptics: SMbus companion is not ready yet
[    1.287961] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1, caps: 0xf008a3/0x943300/0x12e800/0x410000, board id: 3053, fw id: 2491654
[    1.287971] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0
[    2.038184] psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3
[    7.767620] psmouse serio1: synaptics: queried max coordinates: x [..5676], y [..4758]
[    7.799610] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1096..]
[    7.799618] psmouse serio1: synaptics: Trying to set up SMBus access
[    8.335736] psmouse serio3: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3
[81220.734879] psmouse serio3: TrackPoint at rmi4-00.fn03/serio0/input0 lost synchronization, throwing 1 bytes away.
[81220.933317] psmouse serio3: resync failed, issuing reconnect request
[118134.901594] psmouse serio3: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3
[139642.459611] psmouse serio3: TrackPoint at rmi4-00.fn03/serio0/input0 lost synchronization, throwing 1 bytes away.
[139642.933809] psmouse serio3: resync failed, issuing reconnect request


Moreover, when laptop is suspended more than ca 1 hour, after resume the touchpad is working fine.
Comment 38 Jason Zheng 2023-11-17 20:25:46 UTC
(In reply to Przemek from comment #36)
> Similar problem here. Machine is the t440p with changed touchpad from t450
> (it fits and was working fine), some logs:
> 
> [    7.853125] rmi4_smbus 9-002c: registering SMbus-connected sensor
> [    7.904417] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer:
> Synaptics, product: TM3053-008, fw id: 2491654
> [    7.960935] input: Synaptics TM3053-008 as
> /devices/pci0000:00/0000:00:1f.3/i2c-9/9-002c/rmi4-00/input/input20
> [    7.966394] serio: RMI4 PS/2 pass-through port at rmi4-00.fn03
> [    8.373257] input: TPPS/2 IBM TrackPoint as
> /devices/pci0000:00/0000:00:1f.3/i2c-9/9-002c/rmi4-00/rmi4-00.fn03/serio3/
> input/input21
> [81220.734879] psmouse serio3: TrackPoint at rmi4-00.fn03/serio0/input0 lost
> synchronization, throwing 1 bytes away.
> 
> Gentoo/ SuSe Tumbleweed.
> After resume from suspend trackpoint and touchpad doesn't work anymore.

I also have a T440p with the touchpad from the T450. My dmesg log does not show my TrackPoint throwing bytes away; however, I found that reloading the psmouse driver using modprobe temporarily fixes the issue... for a minute.
Comment 39 Jason Zheng 2023-11-17 20:26:09 UTC
(In reply to Przemek from comment #36)
> Similar problem here. Machine is the t440p with changed touchpad from t450
> (it fits and was working fine), some logs:
> 
> [    7.853125] rmi4_smbus 9-002c: registering SMbus-connected sensor
> [    7.904417] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer:
> Synaptics, product: TM3053-008, fw id: 2491654
> [    7.960935] input: Synaptics TM3053-008 as
> /devices/pci0000:00/0000:00:1f.3/i2c-9/9-002c/rmi4-00/input/input20
> [    7.966394] serio: RMI4 PS/2 pass-through port at rmi4-00.fn03
> [    8.373257] input: TPPS/2 IBM TrackPoint as
> /devices/pci0000:00/0000:00:1f.3/i2c-9/9-002c/rmi4-00/rmi4-00.fn03/serio3/
> input/input21
> [81220.734879] psmouse serio3: TrackPoint at rmi4-00.fn03/serio0/input0 lost
> synchronization, throwing 1 bytes away.
> 
> Gentoo/ SuSe Tumbleweed.
> After resume from suspend trackpoint and touchpad doesn't work anymore.

I also have a T440p with the touchpad from the T450. My dmesg log does not show my TrackPoint throwing bytes away; however, I found that reloading the psmouse driver using modprobe temporarily fixes the issue... for a minute.
Comment 40 icebear.loves.cookies 2024-04-23 21:25:56 UTC
Just created an account to say exactly the same thing that's been said over and over and hopefully this can get sorted out.

Thinkpad x395 yoga on Arch linux-lts 6.6.28-1-lts I tried all kernels for arch and nothing.
I'm forced to reload psmouse every time the trackpoint stops working. It seems to be spotty at best. Sometimes it's not detected after boot sometimes it is. It's an Elantech trackpoint. Here's the logs:
[ 6035.568923] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 6035.570351] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 6035.570363] psmouse serio1: issuing reconnect request
[ 6036.332627] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4760]
[ 6036.366980] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1092..]
[ 6275.304399] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 6275.305556] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 6275.305569] psmouse serio1: issuing reconnect request
[ 6276.061561] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4760]
[ 6276.096558] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1092..
This is what gets reported every time it fails. Listed as: I: Bus=0011 Vendor=0002 Product=000a Version=0000
N: Name="TPPS/2 Elan TrackPoint"
P: Phys=synaptics-pt/serio0/input0
S: Sysfs=/devices/platform/i8042/serio1/serio2/input/input19
U: Uniq=
H: Handlers=event8 mouse3 
B: PROP=21
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=3
under /proc/bus/input/devices

Works fine under windows I even upgraded the trackpoint's firmware to see if it helped (it did not)
Comment 41 icebear.loves.cookies 2024-04-23 21:27:21 UTC
(In reply to icebear.loves.cookies from comment #40)
> Just created an account to say exactly the same thing that's been said over
> and over and hopefully this can get sorted out.
> 
> Thinkpad x395 yoga on Arch linux-lts 6.6.28-1-lts I tried all kernels for
> arch and nothing.
> I'm forced to reload psmouse every time the trackpoint stops working. It
> seems to be spotty at best. Sometimes it's not detected after boot sometimes
> it is. It's an Elantech trackpoint. Here's the logs:
> [ 6035.568923] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync
> at byte 1
> [ 6035.570351] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync
> at byte 1
> [ 6035.570363] psmouse serio1: issuing reconnect request
> [ 6036.332627] psmouse serio1: synaptics: queried max coordinates: x
> [..5678], y [..4760]
> [ 6036.366980] psmouse serio1: synaptics: queried min coordinates: x
> [1266..], y [1092..]
> [ 6275.304399] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync
> at byte 1
> [ 6275.305556] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync
> at byte 1
> [ 6275.305569] psmouse serio1: issuing reconnect request
> [ 6276.061561] psmouse serio1: synaptics: queried max coordinates: x
> [..5678], y [..4760]
> [ 6276.096558] psmouse serio1: synaptics: queried min coordinates: x
> [1266..], y [1092..
> This is what gets reported every time it fails. Listed as: I: Bus=0011
> Vendor=0002 Product=000a Version=0000
> N: Name="TPPS/2 Elan TrackPoint"
> P: Phys=synaptics-pt/serio0/input0
> S: Sysfs=/devices/platform/i8042/serio1/serio2/input/input19
> U: Uniq=
> H: Handlers=event8 mouse3 
> B: PROP=21
> B: EV=7
> B: KEY=70000 0 0 0 0
> B: REL=3
> under /proc/bus/input/devices
> 
> Works fine under windows I even upgraded the trackpoint's firmware to see if
> it helped (it did not)

To add to this sometimes when I reload the psmouse module my kernel crashes (you get that blinking caps lock light)
Comment 42 duven 2024-05-30 19:33:15 UTC
I have also made an account just for this error.
For a few weeks now the mouse and keyboard are constantly getting stuck.
I thought it was the temperature and I just changed the thermal paste and removed the dust. It's still the same. On windows I don't have this problem.

I have an old dell n411z with Mint 21.3 and kernel 5.15.0-107-generic installed.

Someone knows to solve it? I will try downgrade/upgrade kernel.


May 30 21:31:41 dell kernel: [ 2071.583338] psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away.
May 30 21:31:56 dell kernel: [ 2086.743999] psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 5 bytes away.
May 30 21:31:59 dell kernel: [ 2089.262962] psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
May 30 21:32:01 dell kernel: [ 2091.786941] psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
May 30 21:32:04 dell kernel: [ 2094.304925] psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
May 30 21:32:47 dell kernel: [ 2137.201502] psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
Comment 43 duven 2024-05-31 14:35:55 UTC
(In reply to duven from comment #42)
> I have also made an account just for this error.
> For a few weeks now the mouse and keyboard are constantly getting stuck.
> I thought it was the temperature and I just changed the thermal paste and
> removed the dust. It's still the same. On windows I don't have this problem.
> 
> I have an old dell n411z with Mint 21.3 and kernel 5.15.0-107-generic
> installed.
> 
> Someone knows to solve it? I will try downgrade/upgrade kernel.
> 
> 
> May 30 21:31:41 dell kernel: [ 2071.583338] psmouse serio1: TouchPad at
> isa0060/serio1/input0 lost synchronization, throwing 2 bytes away.
> May 30 21:31:56 dell kernel: [ 2086.743999] psmouse serio1: TouchPad at
> isa0060/serio1/input0 lost synchronization, throwing 5 bytes away.
> May 30 21:31:59 dell kernel: [ 2089.262962] psmouse serio1: TouchPad at
> isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
> May 30 21:32:01 dell kernel: [ 2091.786941] psmouse serio1: TouchPad at
> isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
> May 30 21:32:04 dell kernel: [ 2094.304925] psmouse serio1: TouchPad at
> isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
> May 30 21:32:47 dell kernel: [ 2137.201502] psmouse serio1: TouchPad at
> isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.

[SOLVED]
Apparently there are several things to consider. The Mint psensor application causes those freezes.
I have also upgraded the BIOS from A00 to A06
and downgraded the kernel to 5.15.0-107-generic.
Now it works correctly.
I can't tell if I had psensor always on.

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