Description of problem: Booting a USB created with dd(dd if=/path/to/iso of=/dev/usbdrive) and moving the mouse once the desktop is loaded causes libinput to seg fault crashing Xorg Version-Release number of selected component (if applicable): Fedora-Live-KDE-x86_64-22-3.iso How reproducible: Always Steps to Reproduce: 1. Boot USB 2. Move mouse 3. Watch Xorg crash and return me to the login screen Actual results: Xorg crashes Expected results: The mouse to move Additional info: Motherboard: ASRock Z170 Gaming-ITX/ac Mouse: ASUS RoG Gladius
Created attachment 1086578 [details] dmidecode
Created attachment 1086579 [details] lsusb
Created attachment 1086580 [details] Xorg Log
what version of libinput is this? pretty sure this got fixed and the xorg-x11-drv-libinput version is really old (0.9.0 as opposed to the current 0.14.0). That suggests libinput will be well out of date too, can you try updating both and see if it still crashes?
It is xorg-x11-drv-libinput-0.9.0-1.fc22 and libinput-0.15.0-1.fc22.x86_64. I can't update them as my ethernet was not support until 4.1, I can try with the F23 beta.
Reproducible in Fedora 23 Beta 1 KDE Spin. libinput-1.0.1-1.fc23.x86_64 xorg-x11-drv-libinput-0.14.0-1.fc23.x86_64
Created attachment 1086706 [details] Xorg log from Fedora 23
Changing version to 23
(In reply to Wesley Hearn from comment #5) > I can't update them as my ethernet was not support until 4.1, I can try with > the F23 beta. fwiw, you could just update libinput + xorg-x11-drv-libinput, they're independent of the kernel. anyway, really odd, this shouldn't happen (well, obviously ;) any chance you can figure out which device this is triggered by? just unplug any devices that you can and try to reproduce one-by-one. my guess is the ASUS ROG GLADIUS one, if it is, please attach the evemu-describe for this device. Looks like it has two kernel devices, event3 and event4, please record both.
I plugged my asus rog into a X1 Carbon and verified it is the mouse causing the crash. Strange as it does not happen in Elementary OS 0.3.1. I will get the evemu-describe output tonight.
Created attachment 1086977 [details] event for first slot
Created attachment 1086978 [details] event for 2nd slot
thanks, reproduced it here. The crash should be easy enough to fix, but the real issue is that the device is weird. The first event node looks like a mouse (rel x/y + buttons), the second one like a keyboard. That's pretty common for gaming mice. But the second event node also has rel x/y and apparently the mouse sends the x/y coordinates through that node. That causes the crash, but it causes another problem: it means the buttons are on a different device than the x/y movements. Benjamin, is there a kernel quirk for this?
(In reply to Peter Hutterer from comment #13) > > Benjamin, is there a kernel quirk for this? Not that I know of. The 2 events nodes are on 2 different interfaces, so it will be quite invasive of a driver if we want to fix that in the kernel. By any chances, did you configured something on the mouse under Windows before using it under Linux?
I did, also keep in mind that it DOES works in other Linux distros.
libinput-1.1.0-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-1150305c5f
Just tested that libinput(pulled from koji) and the mouse is now working with Fedora 23.
Just to check what's going on, pls run evemu-record against both devices and check where the x/y coordinates actually are coming from. Do you see any motion events on the first event node?
Created attachment 1087345 [details] event1 record
Created attachment 1087346 [details] event2 record
wtf? this makes no sense - this device sends events on both device nodes? Please re-run this with both evemu-records running at the same time and monitor them (I don't need the output, just let them print to stdout and keep an eye on both at the same time). Is there any consistency to when an event is sent via a specific event node?
The 2nd event node fires off movement changes like 1 every 20 or so events sent off from the first node.
oh man, that's just depressing. ok, can't do much about this then, and not worth the effort of putting a kernel quirk in. I've got a test for libinput for this now, so at least there shouldn't be any regressions, though I look forward to see what other surprises this mouse has ;) With the libinput patch in, I consider this fixed, now, I'll led bodhi close the bug when hits stable. Thanks for all the help.
libinput-1.1.0-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update libinput' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-1150305c5f
libinput-1.1.0-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-7634f86261
libinput-1.1.0-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update libinput' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-7634f86261
libinput-1.1.0-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.