[Bug 52101] New: In UDEV lnxev mode the winedevice.exe process of winebus.sys crashes on a keypress from the keyboard.
https://bugs.winehq.org/show_bug.cgi?id=52101 Bug ID: 52101 Summary: In UDEV lnxev mode the winedevice.exe process of winebus.sys crashes on a keypress from the keyboard. Product: Wine Version: 6.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: hid Assignee: wine-bugs(a)winehq.org Reporter: logos128(a)gmail.com CC: rbernon(a)codeweavers.com Distribution: ArchLinux Created attachment 71121 --> https://bugs.winehq.org/attachment.cgi?id=71121 winebus_crash_v6.22.log.tar.gz It happens only on an user account with administrator rights (superuser, etc.). As it crashes on a keypress, this makes pretty difficult attaching a debugger to the crashing process :) Found out that lnxev backend doesn't add normal keys to the staged report descriptor, which makes any usb keyboard appear with an empty Input report. The actual crash happens in winebus.sys/main.c process_hid_report(), when it tries to resolve the ext->collection_desc.ReportIDs[0].ReportID. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52101 --- Comment #1 from Ivo Ivanov <logos128(a)gmail.com> --- Created attachment 71123 --> https://bugs.winehq.org/attachment.cgi?id=71123 0001-winebus.sys-Prevent-processing-empty-Input-Reports.patch Attached a patch with a possible fix. Based on the current master 5e42498e634abda051aa59a3faeb2cf10469b1a6 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52101 Ivo Ivanov <logos128(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|In UDEV lnxev mode the |The winebus.sys process |winedevice.exe process of |crashes in lnxev mode when |winebus.sys crashes on a |a keyboard key is pressed. |keypress from the keyboard. | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52101 --- Comment #2 from Rémi Bernon <rbernon(a)codeweavers.com> --- Interesting, although I don't think we're supposed to support keyboard or mouse devices this way, at least not for now, as winebus.sys is really only written for joysticks and gamepad devices. I think the problem is either, that we send a report before the device has been started, or that the device doesn't have any report, or that it's not been started at all maybe because the hidclass.sys driver didn't match it somehow. I guess the first case may also happen with any device if anything is pressed after the device has been created and before it has received the IRP_MN_START_DEVICE request (or after IRP_MN_REMOVE_DEVICE if it's being forcefully removed from the Win32 side). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52101 --- Comment #3 from Ivo Ivanov <logos128(a)gmail.com> --- (In reply to Rémi Bernon from comment #2)
Interesting, although I don't think we're supposed to support keyboard or mouse devices this way, at least not for now, as winebus.sys is really only written for joysticks and gamepad devices.
I agree. Especially mouse devices push a lot of staged Input reports from the lnxev side, which go in the UDEV bus thread together with the reports from hidraw devices. And if there is a hidraw device like mine, which pushes around 1000 input reports per second, all those additional unused reports from mouse devices, etc. only could hinder the performance of the sole thread. IMO, would be good if keyboards and mouse devices are excluded from the enumeration of the UDEV lnxev bus.
I think the problem is either, that we send a report before the device has been started, or that the device doesn't have any report, or that it's not been started at all maybe because the hidclass.sys driver didn't match it somehow.
I guess the first case may also happen with any device if anything is pressed after the device has been created and before it has received the IRP_MN_START_DEVICE request (or after IRP_MN_REMOVE_DEVICE if it's being forcefully removed from the Win32 side).
From the log I could see two instances of the keyboard - /dev/input/event3 -> "SIGMACHIP USB Keyboard" and /dev/input/event5 -> "SIGMACHIP USB Keyboard Consumer Control". After that in the log there are a lot of descriptors with report_len 0, which have collections without usages. They probably cause the issue.
From the code is visible that only buttons from BTN_MISC to KEY_MAX are being enumerated. There is even a comment in build_report_descriptor() about ignoring regular keys and adding only buttons (this is the UDEV lnxev bus with staged HID reports). This IMO produces the empty reports, as probably some of these keyboard devices expose only regular "keys".
-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla