Description of problem: ThinkPad Bluetooth keyboard causes the cursor to disappear or become unresponsive. Version-Release number of selected component (if applicable): Version: 1.10.901 Release: 1.fc29 How reproducible: on Wayland, connect ThinkPad Bluetooth keyboard, access the GNOME Shell overview; on X, make contact with the TrackPoint on the same keyboard. Actual results: on Wayland, after activating the shell overview, the cursor vanishes. I can get it back by disabling Bluetooth from the system menu and switching to a console (Ctrl-Alt-F3) and back. On X, the keyboard works until I touch the TrackPoint. The cursor flies to the shell hot corner, lights up Activities without opening the overview, and stays. My laptop TrackPoint or a USB mouse can then be used to move the cursor. The Bluetooth keyboard can still be used for typing. Expected results: the cursor remains active and accessible when using the Bluetooth keyboard. Additional info: Kernel Version: 4.17.0 Release: 0.rc6.git2.1.fc29, 0.rc6.git3.1.fc29; gnome-shell Version: 3.29.2 Release: 1.fc29 dmesg: [91490.366114] usb 2-7: new full-speed USB device number 7 using xhci_hcd [91490.493583] usb 2-7: New USB device found, idVendor=8087, idProduct=0a2a, bcdDevice= 0.01 [91490.493589] usb 2-7: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [91490.510181] Bluetooth: hci0: read Intel version: 370810011003110e00 [91490.510625] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq [91490.807247] Bluetooth: hci0: Intel firmware patch completed and activated [91491.018110] Bluetooth: hci0: last event is not cmd complete (0x0f) [91508.126555] lenovo 0005:17EF:6048.0008: unknown main item tag 0x0 [91508.127308] input: ThinkPad Compact Bluetooth Keyboard with TrackPoint as /devices/pci0000:00/0000:00:14.0/usb2/2-7/2-7:1.0/bluetooth/hci0/hci0:256/0005:17EF:6048.0008/input/input26 [91508.129208] lenovo 0005:17EF:6048.0008: input,hidraw2: BLUETOOTH HID v3.09 Keyboard [ThinkPad Compact Bluetooth Keyboard with TrackPoint] on a4:02:b9:6d:5e:bf [91589.456678] usb 2-7: USB disconnect, device number 7
Clarification: on Wayland, the first touch of the trackpoint *causes* the shell overview to open, after which the trackpoint is unresponsive.
Also with libinput Version: 1.10.902 Release: 1.fc29, Kernel Version: 4.17.0 Release: 0.rc7.git0.1.fc29.
I have the exact same problem with the versions of libinput currently in updates-testing for F28 (libinput-1.10.902-1.fc28.x86_64 and libinput-before that 1.10.901-1.fc28.x86_64). I've tried on various 4.16.x kernels with same result, but reverting to libinput-1.10.7-1.fc28.x86_64 solves it. However, my keyboard is the *USB* version of the ThinkPad keyboard, not bluetooth.
Is there any chance you can bisect this with git master? I have no idea where this is coming from and I have failed so far to reproduce this with virtual devices (i don't have an external trackpoint). Bisecting is easy enough, running sudo ./build/libinput-debug-gui gives you a GUI where the cursor is controlled by libinput motion events directly. This should be enough to check if the bug is there. You'll need gtk3-devel at meson build time to build that tool. build instructions otherwise are here: https://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html but it's a basic meson build, nothing exciting.
Also, I'll need the libinput debug-events --verbose output from such an event (should show the delta at least) and the udevadm info /sys/class/input/eventX output for the event node from the trackpoint.
I can. Does that debug gui work with the built library in situ or do I need to actually install and restart X?
Works in situ, no restarts needed. I'm hoping it's not some udev-related bug because then you'd have to also run sudo udevadm hwdb --update sudo udevadm trigger /sys/class/input/eventX before each test run. Should be safe to do so anyway though.
$ udevadm info /sys/class/input/event10 P: /devices/pci0000:00/0000:00:14.0/usb3/3-9/3-9.4/3-9.4.2/3-9.4.2:1.1/0003:17EF:6047.0006/input/input12/event10 N: input/event10 S: input/by-id/usb-Lenovo_ThinkPad_Compact_USB_Keyboard_with_TrackPoint-if01-event-mouse S: input/by-path/pci-0000:00:14.0-usb-0:9.4.2:1.1-event-mouse E: DEVLINKS=/dev/input/by-id/usb-Lenovo_ThinkPad_Compact_USB_Keyboard_with_TrackPoint-if01-event-mouse /dev/input/by-path/pci-0000:00:14.0-usb-0:9.4.2:1.1-event-mouse E: DEVNAME=/dev/input/event10 E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-9/3-9.4/3-9.4.2/3-9.4.2:1.1/0003:17EF:6047.0006/input/input12/event10 E: ID_BUS=usb E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_INPUT_MOUSE=1 E: ID_INPUT_POINTINGSTICK=1 E: ID_MODEL=ThinkPad_Compact_USB_Keyboard_with_TrackPoint E: ID_MODEL_ENC=ThinkPad\x20Compact\x20USB\x20Keyboard\x20with\x20TrackPoint E: ID_MODEL_ID=6047 E: ID_PATH=pci-0000:00:14.0-usb-0:9.4.2:1.1 E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_9_4_2_1_1 E: ID_REVISION=0330 E: ID_SERIAL=Lenovo_ThinkPad_Compact_USB_Keyboard_with_TrackPoint E: ID_TYPE=hid E: ID_USB_DRIVER=usbhid E: ID_USB_INTERFACES=:030101:030102: E: ID_USB_INTERFACE_NUM=01 E: ID_VENDOR=Lenovo E: ID_VENDOR_ENC=Lenovo E: ID_VENDOR_ID=17ef E: LIBINPUT_ATTR_TRACKPOINT_SENSITIVITY=5 E: LIBINPUT_DEVICE_GROUP=3/17ef/6047:usb-0000:00:14.0-9.4 E: MAJOR=13 E: MINOR=74 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=5412625
Okay, so, libinput-debug-events gives me event10 POINTER_MOTION +2.22s -0.07/ 0.00 event10 POINTER_MOTION +2.24s -0.62/ -0.21 event10 POINTER_MOTION +2.26s -1.90/ -1.14 event10 POINTER_MOTION +2.27s -4.91/ -3.07 event10 POINTER_MOTION +2.29s -8.32/ -6.66 event10 POINTER_MOTION +2.30s -8.74/ -7.87 event10 POINTER_MOTION +2.32s -7.04/ -6.26 with the old lib, and THIS with the new one -event10 POINTER_MOTION +1.93s inf/ -nan event10 POINTER_MOTION +1.94s inf/ -nan event10 POINTER_MOTION +1.95s inf/ -nan event10 POINTER_MOTION +1.97s inf/ -nan event10 POINTER_MOTION +1.98s inf/ -nan event10 POINTER_MOTION +2.00s inf/ -nan that's some smoking gun stuff right there :)
Workaround from Peter: create /etc/udev/rules.d/99-test.rules with ACTION!="add|change", GOTO="test_end" KERNEL!="event*", GOTO="test_end" ENV{ID_INPUT_POINTINGSTICK}="1", ENV{LIBINPUT_ATTR_TRACKPOINT_SENSITIVITY}="" LABEL="test_end" then run sudo udevadm hwdb --update sudo udevadm trigger /sys/class/input/event10 (or whatever input/eventX corresponds to your device)
libinput-1.10.902-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-088341d6c6
for the archives, ^^ is the revert of the commit that introduced this bug and should make things normal again. It may have effects on some other devices, still looking into this. I'll try to add this bug number to future updates, please keep testing those too so I know if I accidentally break this device again. Thanks.
libinput-1.10.902-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-088341d6c6
libinput-1.10.902-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.