Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

Szymon · 2023-12-02 07:59:09

Hello,

I'm having some problems with the Lenovo Thinkpad Trackpoint Keyboard II. Specifically the problem I'm trying to solve is the very annoying 'middle-click-after-scrolling'
effect when you use the on-keyboard buttons. The issue is described in this post

Quote: "Middle button paste (previously the content was pasted after each scrolling event)"

My problem is that it seems like immediately after plugging in the keyboard, the driver continues to work fine for a non-deterministic period of time (anywhere between a couple of seconds and 1-2 mins) and then the middle button paste events are being sent after scrolling again.

For context, I'm using the keyboard using the 2.4 Ghz dongle in the windows mode. My WM is running on wayland and here is the output of dmesg after I connect the keyboard:

[ 2200.549672] usb 3-7: new full-speed USB device number 9 using xhci_hcd
[ 2200.694810] usb 3-7: New USB device found, idVendor=17ef, idProduct=60ee, bcdDevice= 1.27
[ 2200.694820] usb 3-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2200.694823] usb 3-7: Product: TrackPoint Keyboard II
[ 2200.694826] usb 3-7: Manufacturer: Lenovo
[ 2200.698770] input: Lenovo TrackPoint Keyboard II as /devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.0/0003:17EF:60EE.0019/input/input49
[ 2200.753650] lenovo 0003:17EF:60EE.0019: input,hidraw11: USB HID v1.11 Keyboard [Lenovo TrackPoint Keyboard II] on usb-0000:00:14.0-7/input0
[ 2200.757693] input: Lenovo TrackPoint Keyboard II as /devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.1/0003:17EF:60EE.001A/input/input50
[ 2200.813874] lenovo 0003:17EF:60EE.001A: input,hiddev100,hidraw12: USB HID v1.11 Mouse [Lenovo TrackPoint Keyboard II] on usb-0000:00:14.0-7/input1
[ 2200.817258] lenovo 0003:17EF:60EE.001B: hiddev101,hidraw13: USB HID v1.11 Device [Lenovo TrackPoint Keyboard II] on usb-0000:00:14.0-7/input2

As stated in the linked post, the kernels after 5.19 should include the patch for this keyboard, however it seems like the issue is back.
Could you please help me with investigating the issue?
Is it possible that some new kernel updates have broken it again?
Is there anyone here using this keyboard without issues on their machine?

For reference, my machine has a built-in trackpoint and there are no middle-click-after-scroll issues present.
You can see a related discussion on the lenovo support here
It seems like the root cause is some bug in the keyboard fimware and the kernel patch was supposed to be a workaround.

Thank you!

Last edited by Szymon (2024-02-07 17:24:25)

mulch569 · 2023-12-03 23:28:07

Hello! I have the exact same problem (same keyboard, also using the dongle). It started today after I upgraded the kernel from 6.6.2 to 6.6.3. Haven't yet tried going back to 6.6.2, but will try now.
If you find a solution, please post it here. I will do the same.

mulch569 · 2023-12-03 23:46:28

Downgraded to 6.6.2 and the issue is not present!
Time to look at the diffs, but kernel programming is definitely not my jam.

mulch569 · 2023-12-03 23:55:29

I found this commit in the diff

commit 465b557215664536cd20001872dade2cc4ae2d6a
Author: Jamie Lentin <jm@lentin.co.uk>
Date:   Mon Oct 2 15:09:14 2023 +0000

    hid: lenovo: Resend all settings on reset_resume for compact keyboards
    
    commit 2f2bd7cbd1d1548137b351040dc4e037d18cdfdc upstream.
    
    The USB Compact Keyboard variant requires a reset_resume function to
    restore keyboard configuration after a suspend in some situations. Move
    configuration normally done on probe to lenovo_features_set_cptkbd(), then
    recycle this for use on reset_resume.
    
    Without, the keyboard and driver would end up in an inconsistent state,
    breaking middle-button scrolling amongst other problems, and twiddling
    sysfs values wouldn't help as the middle-button mode won't be set until
    the driver is reloaded.
    
    Tested on a USB and Bluetooth Thinkpad Compact Keyboard.
    
    CC: stable@vger.kernel.org
    Fixes: 94eefa271323 ("HID: lenovo: Use native middle-button mode for compact keyboards")
    Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
    Signed-off-by: Martin Kepplinger <martink@posteo.de>
    Link: https://lore.kernel.org/r/20231002150914.22101-1-martink@posteo.de
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

edit: Sent him an email asking for help.

Last edited by mulch569 (2023-12-04 00:34:17)

lentinj · 2023-12-04 10:04:17

I don't have a TP Compact II, but I don't think it's behaviour is too far away from the older keyboards. It might be worth asking the author of the TP compact II patches.

The patch is definitely related though, and if you're really lucky solves your problem.

mulch569 wrote:

the middle button paste events are being sent after scrolling again.

This is the "default" behaviour of a TP compact keyboard. We need to send a command to make the middle button behave sensibly. The kernel driver sends this as soon as it finds the keyboard.

Older Compact USB keyboards have very similar problems on laptop suspend/resume. The suspend cycle reset the keyboard, so the driver needs to send the middle-button command again. This is what the patch you found does, sends all the config commands on resume.

(this is irrelevant for bluetooth, since a keyboard entirely disconnects & reconnects on resume)

mulch569 wrote:

non-deterministic period of time (anywhere between a couple of seconds and 1-2 mins)

This sounds very much USB autosuspend related. You could try disabling it, e.g. through powertop as a quick fix.

I don't know if reset_resume() gets called after autosuspend. If it does, then the patch will do exactly what you want.

At very least it will mean you could write to fn_lock or sensitivity and restore your middle button functionality (since post-patch these will also send the middle-button command).

mulch569 · 2023-12-04 11:34:59

Thanks lentinj for your insights!

lentinj wrote:

This is the "default" behaviour of a TP compact keyboard. We need to send a command to make the middle button behave sensibly. The kernel driver sends this as soon as it finds the keyboard.

That's interesting. Will play with it to try to create a userland fix.

Szymon · 2023-12-04 14:55:21

Thank you mulch569 and lentinj for helping me investigate the issue. One thing I'm not sure about is that the keyboard I'm using is the Thinkpad Wireless Keyboard II, which to my understanding behaves in a different way than the USB and Bluetooth Thinkpad Compact Keyboard that was used for testing. I will try to disable the autosuspend and see if that fixes the issue.
As for the default behaviour, is it indeed the case that after you stop scrolling with the middle button the keyboard sends an additional middle button press? It causes undesired issues where e.g. if I scroll a web page and after scrolling the cursor lands on a link, the middle button is pressed on release of the scrolling and i end up with that linked opened in a new tab (which is the expected behaviour of a single middle button click). To my understanding the kernel patch that I linked in my original post aimed to fix it at the kernel level (as the keyboard sends those keypresses anyway I think) Do you know whom I should contact to investigate the state of TP Compact II patches?
I will try playing aroud with powertop to prevent that usb autosuspend. Anyways thanks for helping me dig into this, much appreciated.

Edit: I have checked powertop and it seems like autosuspend is disabled for that device

In which case would you say downgrading the kernel is the only option right now to restore the previous behaviour where no middle clicks are registered after releasing the middle button that was held down for scrolling?

I have investigated the issue using xev and it seems like there is something happening almost immediately after I plug the keyboard in, the test went as follows:
-> unplug the keyboard
-> plug it back in
-> launch xev
-> start scrolling
-> for the first couple of seconds no middle button clicks are registered after scrolling is released
-> after that something changes (the keyboard is constantly being used with the trackpoint so an autosuspend is unlikely)
-> the subsequent tests show that after scrolling the middle button click is registered, as in, the keyboard is back to the 'default' state .

Do you have any ideas as to what might be causing the issue? Could it be that the new patch for the TP Compact USB keyboard gets executed and messes something up with the settings of the driver?

Last edited by Szymon (2023-12-04 15:12:17)

mulch569 · 2023-12-04 23:14:01

the keyboard I'm using is the Thinkpad Wireless Keyboard II, which to my understanding behaves in a different way than the USB and Bluetooth Thinkpad Compact Keyboard

That's the same keyboard I'm using. Have you tried connecting via bluetooth instead of using the dongle?

As for the default behaviour, is it indeed the case that after you stop scrolling with the middle button the keyboard sends an additional middle button press?

I think that lentinj is saying that pasting after scrolling is the default behavior of the keyboard in Linux without any patches. And since it is definitely annoying, the kernel driver that they wrote was doing something to prevent that behavior.

Now that I read lentinj's response again, I'm confused.

I've been using this keyboard for almost two years with many kernel versions, and just as I installed 6.6.3 the issues began. And as soon as I rolled back to 6.6.2 everything went back to normal. I will stay in 6.6.2 until I have some time to try to fix it (hopefully this weekend).

e.g. if I scroll a web page and after scrolling the cursor lands on a link, the middle button is pressed on release of the scrolling and i end up with that linked opened in a new tab (which is the expected behaviour of a single middle button click).

Yes, the same happened to me, and I found it weird. But the fact that I couldn't scroll inside my IDE/terminal without pasting was the deal-breaker.

Could it be that the new patch for the TP Compact USB keyboard gets executed and messes something up with the settings of the driver?

I suspect the same

Last edited by mulch569 (2023-12-04 23:15:10)

chirs241097 · 2023-12-05 19:51:33

I've got the exact same issue with the same keyboard here. Tried manually reverting commit 46a0a2c and rebuilt the 6.6.3 kernel. Now the issue seems to be gone. Not tested on 6.6.4 yet.

Szymon · 2023-12-05 21:32:19

I just tested 6.6.4 today and it seems that the issue persists. It might be worth reaching out to the kernel maintainers responsible for that commit. Do you know what's the preferred pathway for reporting such issues?

Edit 11.12.2023: Do you know if there has been any progress made on this issue?
For now I think I'm going to stick to kernel 6.6.2 and avoid the updates before the issue gets resolved.

Update 12.12.2023: I contacted the author of the kernel patch that was causing the issue. He has already submitted a fix which will only enable that change for the correct (TP usb compact) keyboard and leave the TP Trackpoint keyboard II unaffected. Once the patch lands in the stable kernel and gets included in the arch repos, we should be able to use the keyboard without any issues with the latest kernel.

Last edited by Szymon (2023-12-12 16:55:21)

mulch569 · 2023-12-13 14:59:13

Szymon wrote:

Update 12.12.2023: I contacted the author of the kernel patch that was causing the issue. He has already submitted a fix which will only enable that change for the correct (TP usb compact) keyboard and leave the TP Trackpoint keyboard II unaffected. Once the patch lands in the stable kernel and gets included in the arch repos, we should be able to use the keyboard without any issues with the latest kernel.

Thanks Szymon! I haven't got time to look more into this issue, so I stayed in 6.6.2. Great to hear a fix will land eventually

gjvc · 2023-12-16 01:34:59

I have built and am running 88035e5694a86a7167d490bb95e9df97a9bb162b which is the merge of "hid-for-linus-2023121201". I am not sure if there has been a regression on this matter between this commit and 6.7.0-rc5 because I was seeing the same behaviour (paste-after-scroll starting after some arbitrary length of time) on my KU-1255 when running the latter commit. (Of course, I could have messed something else up myself)

Edit: thus far, none of the fixes work for my hardware:

> lsusb | grep -i keyboard
Bus 001 Device 003: ID 17ef:6047 Lenovo ThinkPad Compact Keyboard with TrackPoint

BTW, thank you all on this thread for proving, once again, that Arch continues to have the best wiki and fora for esoteric problems such as this. I was unable to find this matter discussed anywhere else.

Last edited by gjvc (2023-12-17 00:14:09)

mulch569 · 2023-12-17 01:42:15

Szymon, finally got time to try a temporary workaround.

One easy option is to unload the hid-lenovo module:

modprobe -r hid-lenovo

The keyboard works for typing and moving the pointer, but no scrolling and other things.

The better but more involved solution is to build the hid-lenovo driver module for the target linux kernel version, using the old version of the source of

hid-lenovo.c

and load that.
The steps are:
- Get the source code of the linux kernel you want to use (let's say 6.6.7)
- Replace drivers/hid/hid-lenovo.c code with the 6.6.2 version (https://git.kernel.org/pub/scm/linux/ke … c?h=v6.6.2)
- Build the module running the following inside drivers/hid/

make -C /usr/lib/modules/$(uname -r)/build/ M=$(pwd) modules

- (You must have the linux-headers of the target linux kernel installed)
- (If you get any errors, try just building hid-lenovo.c with `echo "obj-$(CONFIG_HID_LENOVO) += hid-lenovo.o" > Makefile` and running the command again)
- Now you should have a hid-lenovo.ko file that you can load with

insmod hid-lenovo.ko

(make sure to unload it first with `modeprobe -r`)

If you are using 6.6.7, here it is compiled: https://0x0.st/HYQJ.ko/hid-lenovo.ko

m101 · 2023-12-19 20:44:26

gjvc wrote:

I was seeing the same behaviour (paste-after-scroll starting after some arbitrary length of time) on my KU-1255 when running the latter commit.

Same issue here. Using the KU-1255 (USB cable) keyboard ("Lenovo ThinkPad Compact Keyboard with TrackPoint"), identified in hid-ids.h through

#define USB_DEVICE_ID_LENOVO_CUSBKBD	0x6047

This is the only type of keyboard where "stop applying workaround" can be triggered in the newest patched version of hid-lenovo.c

		if (hdev->product == USB_DEVICE_ID_LENOVO_CUSBKBD &&
				cptkbd_data->middlebutton_state == 1 &&
				usage->type == EV_REL &&
				(usage->code == REL_X || usage->code == REL_Y))

My keyboard has the original firmware, and, ever since 6.6.3 (which includes this commit) I get the same false behavior of paste-after-scroll described above. The issue starts after reboot (or re-loading hid-lenovo) after some apparently random amount of time. I suppose the "stop applying workaround" condition is triggered at some point, though it is unclear to me why. It would be useful if some more users of the KU-1255 keyboard with original firmware could comment here to confirm that the latest patch to hid-lenovo.c does not fix the issue.

Last edited by m101 (2023-12-19 20:53:43)

saveman71 · 2024-01-23 16:04:14

I have the original keyboard (USB version) and can confirm it started behaving weirdly after a kernel upgrade I did 2 days ago, but it just started behaving wrongly like 1h ago, after multiple suspend cycles (I don't upgrade that often, don't shame me).

Firstly, thanks so much for creating that thread! Immensely useful, after 5mn I thought I was the only one to have the problem, but there it was after a bit of digging after I isolated the problem to `hid-lenovo`. At first, I thought it wasn't loaded, but it was, so that's not it.

I've become used to unplugging and replugging the keyboard as it has been known to be quite unreliable (due to those suspend issues, pointer drift, etc.), but it had no effect.

So after confirming the module was loaded and that power cycle the kb had no effect, I tried this:

mulch569 wrote:

One easy option is to unload the hid-lenovo module:
modprobe -r hid-lenovo
The keyboard works for typing and moving the pointer, but no scrolling and other things.

The kb stopped working (expected), but instead of reloading the module, I tried to power cycle the keyboard again. This loaded the kernel module again and the keyboard now works as expected. So it's another workaround I can use when it occasionally fails.

I'm on 6.7.0, for what it's worth.

Last edited by saveman71 (2024-01-23 16:04:56)

loacker · 2024-01-26 13:41:58

I recently came upon this thread and decided to remove the temporary configuration I had created to address the bothersome effect of the text pasting or links opening automatically after scrolling.
I disabled the middle button pasting with the following command, the downside of it is that you have to highlight the text and use shift+ins to paste it instead of click the middle button to do it like in any default Thinkpad laptop setup.

I added this xinput command to disable the button number 2 in the ~/.xinitrc

idx=$(xinput list | awk -F= '/Lenovo TrackPoint Keyboard II/ && /pointer/ {print substr($2,1,2)}')
for i in ${idx}; do xinput set-button-map ${i} 1 0 3; done

I've now reversed the xinput setup, and it appears that "kernel 6.7.1-arch1-1" is operating correctly.

idx=$(xinput list | awk -F= '/Lenovo TrackPoint Keyboard II/ && /pointer/ {print substr($2,1,2)}')
for i in ${idx}; do xinput set-button-map ${i} 1 2 3; done

I can highlight text and paste it using the middle button, and I can scroll without the bothersome clicking of links or the text automatically pasting upon release.

Last edited by loacker (2024-01-26 14:55:34)

m101 · 2024-01-27 03:46:58

Good news for those affected, a patch was made available that fixes these issues, see https://lore.kernel.org/all/20231223191 … sky.org/T/.
The patch was applied two days ago *to linux-next ( Jan 24 2024).

Looking at the relevant driver in kernel/git/next/linux-next.git (drivers/hid/hid-lenovo.c), the lines of code which caused the problem were indeed removed, see https://git.kernel.org/pub/scm/linux/ke … t-20240125

Last edited by m101 (2024-02-07 17:15:10)

Szymon · 2024-02-05 22:11:01

That's great to hear, thanks for letting us know!
I tested it again on my keyboard (the Trackpoint Keyboard II - not the usb one) and it seems like the middle
click issue after scrolling is gone. That's great news!
For reference, I'm running the 6.7.1-arch1-1 kernel version.
Thanks everyone involved in this conversation. I'm gonna mark it as solved now.

m101 · 2024-02-07 17:14:10

Szymon wrote:

I tested it again on my keyboard (the Trackpoint Keyboard II - not the usb one) and it seems like the middle
click issue after scrolling is gone.

Very interesting -- I checked and the patch is actually not yet included in the arch kernel (see https://github.com/archlinux/linux/blob … d-lenovo.c).
Not sure if this was addressed differently?

Szymon · 2024-02-07 17:23:43

That's very interesting indeed. Good observation.

I double-checked, and I think the reason it works fine for me is that I'm using the wireless keyboard II and I was waiting for the patch that was committed on the 12th of December ( here )
It seems like the fix that I needed was to just restrict the previous problematic patch (the one from September 2023) so that it doesn't act on the second generation of the keyboard.
It could be the case that the other patch (the one applied on the 24th of Jan) is the one that aims to fix the issues with the original usb compact keyboard that were reported by saveman71 and m101.
I think we would need them to confirm that their hardware is fixed.

For now I'm going to revert that update to the post title.
From my experience over the past two days, the second version of the keyboard works flawlessly which is very exciting.

bjo · 2024-02-15 12:22:10

In 6.7.4 unfortunately it's still not fixed: https://git.kernel.org/pub/scm/linux/ke … c?h=v6.7.4

I created an issue, maybe the patch gets implemented before it lands in mainline: https://gitlab.archlinux.org/archlinux/ … /issues/30

Last edited by bjo (2024-02-15 15:04:31)

bjo · 2024-03-26 23:06:51

Fortunately the fix landed in 6.8.2: https://git.kernel.org/pub/scm/linux/ke … 8701d6f076

Arch Linux

#1 2023-12-02 07:59:09

Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#2 2023-12-03 23:28:07

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#3 2023-12-03 23:46:28

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#4 2023-12-03 23:55:29

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#5 2023-12-04 10:04:17

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#6 2023-12-04 11:34:59

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#7 2023-12-04 14:55:21

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#8 2023-12-04 23:14:01

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#9 2023-12-05 19:51:33

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#10 2023-12-05 21:32:19

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#11 2023-12-13 14:59:13

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#12 2023-12-16 01:34:59

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#13 2023-12-17 01:42:15

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#14 2023-12-19 20:44:26

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#15 2024-01-23 16:04:14

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#16 2024-01-26 13:41:58

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#17 2024-01-27 03:46:58

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#18 2024-02-05 22:11:01

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#19 2024-02-07 17:14:10

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#20 2024-02-07 17:23:43

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#21 2024-02-15 12:22:10

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

#22 2024-03-26 23:06:51

Re: Lenovo Thinkpad Trackpoint Keyboard II - Driver Issues

Board footer