Description of problem: If have two different notebooks both running Fedora 26, on one notebook the TrackPoint of my Lenovo ThinkPad Compact USB Keyboard works but on the other it doesn't. The output from libinput list-devices is the same for both systems (related to the keyboard/trackpoint), same as the output from loginctl seat-status seat0 (equal on both systems). The output from udevadm info /dev/input/event... is also the same on both systems. The only difference I see on both systems is that the input device isn't opened by systemd-logind in lsof; Most of the devices in /dev/input are opened except for the TrackPoint and the accelerometer. When I run evtest for the TrackPoint I get output when I touch the trackpoint. I'm using Gnome/Wayland to test the TrackPoint and it doesn't work in GDM nor gnome-shell. The system that works has an builtin TrackPoint (Alps), maybe that's a clue?
I just found out that downgrading libinput fixes this issue.
install the broken libinput please and run libinput debug-events --verbose, then attach the output here. If you don't restart your session, you can downgrade again without any issues. Thanks
Created attachment 1349749 [details] libinput-debug-events-verbose.txt
Created attachment 1349750 [details] gdb-backtrace.txt
If I remove the hp_wmi module libinput debug-events --verbose doesn't abort.
That would indicate it's related to bug 1508741 but it still shouldn't crash. I really need an evemu-record of the Lenovo ThinkPad Compact USB Keyboard with TrackPoint device to add to my test devices. It's detected as internal keyboard and that's not correct.
Created attachment 1350344 [details] evemu-record-17EF:6047.000A.txt this is the keyboard part of the Lenovo ThinkPad Compact USB Keyboard with TrackPoint
Created attachment 1350345 [details] evemu-record-17EF:6047.000B.txt This is the TrackPoint part of the Lenovo ThinkPad Compact USB Keyboard with TrackPoint
A bit stumped by this one, tbh. I can reproduce it here if I re-create the devices with evemu (wmi hotkeys device from bug 1508741) and set the wmi hotkeys switch state to 1 with evemu-event. But I can only reproduce it with the fedora package (even locally built ones) but not with the git tree, even when using the same compiler flags. valgrind doesn't complain about anything, gdb suggests that we jump from print_switch_event into print_proximity_event where the abort happens. But printing the event itself shows everything is fine. It looks like there's some memory corruption happening but I can't seem to find where.
nevermind, found it. gdb just gave me a bogus backtrace, the issue is a plain abort() in the switch handling because that type of switch is unhandled. patch coming up.
libinput-1.9.1-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f637d4d5f3
Thanks! I've installed libinput-1.9.1-3.fc27.x86_64.rpm on Fedora 26 and this fixed the issue.
libinput-1.9.1-3.fc27 has been pushed to the Fedora 27 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-2017-f637d4d5f3
libinput-1.9.1-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-fea77d13b4
Three separate bugs here: * the abort on libinput debug-events, fixed with libinput-1.9.1-3 * libinput thinking the compact keyboard thingy is an internal keyboard, fixed with libinput-1.9.1-4.fc27. This means the keyboard remains active in tablet mode or when the lid switch is closed. * the internal keyboard being disabled, that is bug 1508741 This bug will close when -4 hits stable.
libinput-1.9.1-4.fc27 has been pushed to the Fedora 27 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-2017-fea77d13b4
For what it's worth, installing libinput-1.9.1-4.fc27 also fixes the trackpoint not working on my W541 (and probably a bunch of other recent-ish Lenovo ThinkPads). Note that the trackpoint works just fine out of the box with Fedora 27 on my much older T510.
Artom: if if it was broken pre 1.9.1 I'll need a bugreport for that, the W541 trackpoint shouldn't have been affected at all by any recent updates. thanks
I downgraded to 1.9.0-1.fc27 and my trackpoint still works. It really did not work, and it really did start working when I installed libinput 1.9.1-4.fc27 and rebooted. Maybe it was a coincidence. Are there are config files that are generated by the installation that could persist through a downgrade?
I also have trouble when the HP laptop is docked, when I modprobe -r hp_wmi and reconnect the keyboard the trackpoint works...
the only configuration files we have with libinput are hwdb quirks but they get refreshed on rpm install. So nothing should stick around. Most likely it was the reboot that changed things and updates in some other package (kernel maybe?)
> the only configuration files we have with libinput are hwdb quirks but they > get refreshed on rpm install. So nothing should stick around. Most likely it > was the reboot that changed things and updates in some other package (kernel > maybe?) Entirely possible. I wasn't really keeping track prior to installing 1.9.1-4.fc27 and rebooting.
libinput-1.9.1-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.