Bug 1275407

Summary: ASUS RoG Gladius crashes Xorg when sending movement events.
Product: [Fedora] Fedora Reporter: Wesley Hearn <whearn>
Component: xorg-x11-drv-libinputAssignee: Peter Hutterer <peter.hutterer>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: btissoir, hdegoede, peter.hutterer, whearn
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-04 20:52:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmidecode
none
lsusb
none
Xorg Log
none
Xorg log from Fedora 23
none
event for first slot
none
event for 2nd slot
none
event1 record
none
event2 record none

Description Wesley Hearn 2015-10-26 20:12:31 UTC
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

Comment 1 Wesley Hearn 2015-10-26 20:12:48 UTC
Created attachment 1086578 [details]
dmidecode

Comment 2 Wesley Hearn 2015-10-26 20:13:08 UTC
Created attachment 1086579 [details]
lsusb

Comment 3 Wesley Hearn 2015-10-26 20:13:30 UTC
Created attachment 1086580 [details]
Xorg Log

Comment 4 Peter Hutterer 2015-10-27 02:26:38 UTC
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?

Comment 5 Wesley Hearn 2015-10-27 03:26:50 UTC
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.

Comment 6 Wesley Hearn 2015-10-27 03:57:13 UTC
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

Comment 7 Wesley Hearn 2015-10-27 03:57:52 UTC
Created attachment 1086706 [details]
Xorg log from Fedora 23

Comment 8 Wesley Hearn 2015-10-27 03:58:17 UTC
Changing version to 23

Comment 9 Peter Hutterer 2015-10-27 04:24:42 UTC
(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.

Comment 10 Wesley Hearn 2015-10-27 17:20:21 UTC
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.

Comment 11 Wesley Hearn 2015-10-27 18:36:15 UTC
Created attachment 1086977 [details]
event for first slot

Comment 12 Wesley Hearn 2015-10-27 18:36:34 UTC
Created attachment 1086978 [details]
event for 2nd slot

Comment 13 Peter Hutterer 2015-10-27 22:21:05 UTC
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?

Comment 14 Benjamin Tissoires 2015-10-27 23:12:28 UTC
(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?

Comment 15 Wesley Hearn 2015-10-28 01:08:38 UTC
I did, also keep in mind that it DOES works in other Linux distros.

Comment 16 Fedora Update System 2015-10-28 01:32:23 UTC
libinput-1.1.0-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-1150305c5f

Comment 17 Wesley Hearn 2015-10-28 02:40:15 UTC
Just tested that libinput(pulled from koji) and the mouse is now working with Fedora 23.

Comment 18 Peter Hutterer 2015-10-28 22:35:34 UTC
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?

Comment 19 Wesley Hearn 2015-10-29 02:03:43 UTC
Created attachment 1087345 [details]
event1 record

Comment 20 Wesley Hearn 2015-10-29 02:04:14 UTC
Created attachment 1087346 [details]
event2 record

Comment 21 Peter Hutterer 2015-10-29 02:18:39 UTC
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?

Comment 22 Wesley Hearn 2015-10-29 02:36:29 UTC
The 2nd event node fires off movement changes like 1 every 20 or so events sent off from the first node.

Comment 23 Peter Hutterer 2015-10-30 01:16:14 UTC
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.

Comment 24 Fedora Update System 2015-11-01 06:59:31 UTC
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

Comment 25 Fedora Update System 2015-11-02 02:17:49 UTC
libinput-1.1.0-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-7634f86261

Comment 26 Fedora Update System 2015-11-03 00:24:51 UTC
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

Comment 27 Fedora Update System 2015-11-04 20:52:09 UTC
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.