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