hid-lenovo breaks middle mouse button on tpIIkbd

hid-lenovo breaks middle mouse button on tpIIkbd

[Harald Welte]

Dear ValdikSS,
Dear Linux Input maintainers,

I've recently acquired a brand new tpIIkbd (ThinkPad TrackPoint Keyboard II)
which I use via bloetooth.  Sadly, the center mouse button never worked and
I finally got to try to debug what's going on here.

The keyboard has a small slider swithc to select between Android and
Windows mode.  I've set it to "windows" mode, but couldn't observe any
difference in the bug in both modes.

The keyboard shows up as /sys/kernel/debug/hid/0005:17EF:60E1.000F

== btmon

* the events are visible on bluetooth with "BTMON". Middle mouse button
  press+release looks like this:

> ACL Data RX: Handle 10 flags 0x02 dlen 11                                          #32 [hci0] 14.353057
      ATT: Handle Value Notification (0x1b) len 6
        Handle: 0x001c
          Data[4]: 04000000
> ACL Data RX: Handle 10 flags 0x02 dlen 11                                          #33 [hci0] 15.357078
      ATT: Handle Value Notification (0x1b) len 6
        Handle: 0x001c
          Data[4]: 00000000

== bluetoothd

* bluetoothd is feeding those into uhid (I checked this via strace,
  looks like this:

read(30, "\x1b\x1c\x00\x04\x00\x00\x00", 23) = 7
writev(33, [{iov_base="\x0c\x00\x00\x00\x05\x00\x02\x04\x00 ...

where '30' is the L2CAP socket and '33' is the /dev/uhid device


== /sys/kernel/debug/hid/*/event

/sys/kernel/debug/hid/*/event:

report (size 5) (numbered) =  02 04 00 00 00
Button.0001 = 0
Button.0002 = 0
Button.0003 = 1
GenericDesktop.X = 0
GenericDesktop.Y = 0
GenericDesktop.Wheel = 0

== evtest

However, evtest shows exactly nothing when the centre button is pressed
or depressed.  It works just fine for left and right button.

so somehow the events that look perfectly valid on btmon and as HID event
are lost between /dev/uhid and /dev/event*

When I rmmod the hid-lenovo module, it suddenly starts working and the
evnets are showing up in evtest (and I can start to paste the buffer
with the center button like on any other mouse/trackpad).

There are some BTN_MIDDLE quirks/workarounds in hid-lenovo.c that I don't
understand (I'm not a HID or linux input expert at all).  But my best
guess at this point is that either that code is broken, or Lenovo has
released a new version of that keyboard [or its firmware] which doesn't
need the workaround designed for earlier versions?

Having the module loaded but doing
echo 0 > /sys/devices/virtual/misc/uhid/0005:17EF:60E1.000F/middleclick_workaround
will *not* fix the bug.  The middle button is not working for both 1 or
0 in that middleclick_workaround file.

Regards,
	Harald

-- 
- Harald Welte <laforge@gnumonks.org>          https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: hid-lenovo breaks middle mouse button on tpIIkbd

[ValdikSS]

On 07.09.2024 13:18, Harald Welte wrote:
> Dear ValdikSS,
> Dear Linux Input maintainers,

Hello Harald,
Nice to meet you, I know you from Osmocom project!

You found a REGRESSION (and not in hid_lenovo)! Look below.

> The keyboard has a small slider swithc to select between Android and
> Windows mode.  I've set it to "windows" mode, but couldn't observe any
> difference in the bug in both modes.

You need to use Windows mode only. Android mode does not have all the 
capabilities.

> The keyboard shows up as /sys/kernel/debug/hid/0005:17EF:60E1.000F

Same for me.

> 
> == btmon
> 
> * the events are visible on bluetooth with "BTMON". Middle mouse button
>    press+release looks like this:
> 
>> ACL Data RX: Handle 10 flags 0x02 dlen 11
>        ATT: Handle Value Notification (0x1b) len 6
>          Handle: 0x001c
>            Data[4]: 04000000
>> ACL Data RX: Handle 10 flags 0x02 dlen 11
>        ATT: Handle Value Notification (0x1b) len 6
>          Handle: 0x001c
>            Data[4]: 00000000

Hrm, these events are generated when the keyboard is not in "native" 
mode (when the kernel module is not loaded for example).

Here's what the middle button should generate in "native" mode (over 
Bluetooth):

> ACL Data RX: Handle 2048 flags 0x02 dlen 15
       ATT: Handle Value Notification (0x1b) len 10
         Handle: 0x0024
           Data[8]: 0004020000000000
> ACL Data RX: Handle 2048 flags 0x02 dlen 15
       ATT: Handle Value Notification (0x1b) len 10
         Handle: 0x0024
           Data[8]: 0000020000000000


But you're right, something does not work correctly.

The keyboard correctly enters native mode only after pairing or full 
Bluetooth reloading. Middle button does not work for me if the keyboard 
is just disconnected or powered off/on.

This seems to be because Bluetooth layer does not disconnect the input 
device upon disconnecting Bluetooth, and reconnecting the keyboard just 
"resumes" the input device, but does not re-initialize it properly. You 
can see that by not-lid left LED indicator (ESC button). It should be 
lid by default if initialized properly.

I haven't thoroughly used the keyboard for about a year, and last time I 
used it, I don't remember such issue.

Just booted up Fedora 39 from ISO (not updated, release from November 
2023) on 2 of my computers, and yes, it works correctly: the keyboard is 
detected as new input device (in dmesg) on every power off/power on 
cycle, and initialized correctly every time, middle button works.

Fedora 40 ISO (from 15 Apr 2024) — does not work, power off/power on 
results in broken middle button, keyboard is NOT detected as new input 
device in dmesg upon off/on (it "resumes" old input device).

Known good configuration from Fedora 39:
kernel 6.5.6
bluez 5.69

Known bad configuration from Fedora 40:
kernel 6.8.5
bluez 5.73

Old Fedora 39 doesn't ever detect the keyboard as "bluez-hog-device", 
maybe that could be the clue.
All I can say is that lenovo_hid is not the culprit — I tried to use my 
old module and it doesn't work on a new system either.

I don't have much time to run bisect right now, sorry.

Re: hid-lenovo breaks middle mouse button on tpIIkbd

[ValdikSS]

On 11.09.2024 01:07, ValdikSS wrote:
> You found a REGRESSION (and not in hid_lenovo)! Look below.
 >
> The keyboard correctly enters native mode only after pairing or full 
> Bluetooth reloading. Middle button does not work for me if the keyboard 
> is just disconnected or powered off/on.
> 
> This seems to be because Bluetooth layer does not disconnect the input 
> device upon disconnecting Bluetooth, and reconnecting the keyboard just 
> "resumes" the input device, but does not re-initialize it properly. You 
> can see that by not-lid left LED indicator (ESC button). It should be 
> lid by default if initialized properly.
 >
> Known good configuration from Fedora 39:
> kernel 6.5.6
> bluez 5.69


The regression is caused by bluez:
https://github.com/bluez/bluez/issues/949

Re: hid-lenovo breaks middle mouse button on tpIIkbd

[Harald Welte]

Hi ValdikSS,

thanks for your follow-up and investigation. Sorry for pointing the finger
in the wrong direction. It's weird to me that the problem can be worked around
reliably by unloading / blacklisting hid-lenovo.  But then, as I said, I have
no real knowledge about either bluetoth or the input layer..

On Wed, Sep 11, 2024 at 02:51:27AM +0300, ValdikSS wrote:
> On 11.09.2024 01:07, ValdikSS wrote:
> > You found a REGRESSION (and not in hid_lenovo)! Look below.
> >
> > [...]
> 
> The regression is caused by bluez:
> https://github.com/bluez/bluez/issues/949

Thanks, let's ee what the bluez maintainers have to say...

-- 
- Harald Welte <laforge@gnumonks.org>          https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)