Using Rawhide, with kernel Version : 4.17.0 Release : 0.rc6.git3.1.fc29 (also 0.rc6.git2.1.fc29) Architecture: x86_64
and libinput Version : 1.10.901 Release : 1.fc29
my ThinkPad Bluetooth keyboard causes the cursor to disappear or become unresponsive.
On Wayland, after activating the shell overview, the cursor vanishes. I can get it back by disabling Bluetooth from the system menu and (seemingly) switching to a console 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.
Here's what dmesg says: [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
Does this sound like a kernel bug?
Mike
On 05/28/2018 06:17 AM, Michael Hill wrote:
Using Rawhide, with kernel Version : 4.17.0 Release : 0.rc6.git3.1.fc29 (also 0.rc6.git2.1.fc29) Architecture: x86_64
and libinput Version : 1.10.901 Release : 1.fc29
my ThinkPad Bluetooth keyboard causes the cursor to disappear or become unresponsive.
On Wayland, after activating the shell overview, the cursor vanishes. I can get it back by disabling Bluetooth from the system menu and (seemingly) switching to a console 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.
Here's what dmesg says: [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
Does this sound like a kernel bug?
Mike
Possibly. The best thing to do is file a bugzilla for tracking if you haven't already.
On Mon, May 28, 2018 at 09:17:52AM -0400, Michael Hill wrote:
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.
I have this same problem, although with a USB keyboard rather than bluetooth.
Does this sound like a kernel bug?
I think it's a regresion in the version of libinput in updates-testing. Backing out to the older version solves it. See https://bodhi.fedoraproject.org/updates/FEDORA-2018-899c7219fe
I intend to file a bug when I get a chance tonight, but if you beat me to it please let me know the bug number.
On Thu, May 31, 2018 at 04:54:10PM -0400, Matthew Miller wrote:
I think it's a regresion in the version of libinput in updates-testing. Backing out to the older version solves it. See
Also, I should add: changing kernels does not :)
On GNOME IRC, a couple of people suggested libinput, and I found a bug from last week that Peter Hutterer had reassigned to the kernel. I filed this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1583324
Mike
On Thu, May 31, 2018 at 4:59 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, May 31, 2018 at 04:54:10PM -0400, Matthew Miller wrote:
I think it's a regresion in the version of libinput in updates-testing. Backing out to the older version solves it. See
Also, I should add: changing kernels does not :)
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
On Thu, May 31, 2018 at 05:14:05PM -0400, Michael Hill wrote:
On GNOME IRC, a couple of people suggested libinput, and I found a bug from last week that Peter Hutterer had reassigned to the kernel. I filed this bug:
Awesome -- thanks.
On Thu, May 31, 2018 at 05:26:21PM -0400, Matthew Miller wrote:
On Thu, May 31, 2018 at 05:14:05PM -0400, Michael Hill wrote:
On GNOME IRC, a couple of people suggested libinput, and I found a bug from last week that Peter Hutterer had reassigned to the kernel. I filed this bug:
Awesome -- thanks.
In case someone reads this before the bugzilla email :)
I really struggle to reproduce this here, the only potential culprit so far is a NaN for the trackpoint range. This is trival to bisect on the affected machines, so narrowing this down would really help. We're in rc2 territory, I'd rather get this fixed before the 1.11 release. It would look bad ;)
Cheers, Peter
On Thu, May 31, 2018 at 7:42 PM, Peter Hutterer peter.hutterer@who-t.net wrote:
I really struggle to reproduce this here, the only potential culprit so far is a NaN for the trackpoint range. This is trival to bisect on the affected machines, so narrowing this down would really help. We're in rc2 territory, I'd rather get this fixed before the 1.11 release. It would look bad ;)
Peter, libinput-1.10.902-2.fc28 works for me.
Thanks,
Mike
On Fri, Jun 01, 2018 at 03:30:27PM -0400, Michael Hill wrote:
On Thu, May 31, 2018 at 7:42 PM, Peter Hutterer peter.hutterer@who-t.net wrote:
I really struggle to reproduce this here, the only potential culprit so far is a NaN for the trackpoint range. This is trival to bisect on the affected machines, so narrowing this down would really help. We're in rc2 territory, I'd rather get this fixed before the 1.11 release. It would look bad ;)
Peter, libinput-1.10.902-2.fc28 works for me.
rightyo, thanks for testing, much appreciated. I spent most of today looking at trackpoint stuff (and, completely unrelated, a significant part of today sighing, swearing and despairing) so while I'll just get libinput 1.11 out with the revert as in 902-2, libinput 1.12 should hopefully possibly maybe this time really fix trackpoint acceleration.
Cheers, Peter
kernel@lists.fedoraproject.org
-
Laura Abbott -
Matthew Miller -
Michael Hill -
Peter Hutterer