[Bug 52101] New: In UDEV lnxev mode the winedevice.exe process of winebus.sys crashes on a keypress from the keyboard.

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
                CC: [e-mail]
      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.

[Bug 52101] In UDEV lnxev mode the winedevice.exe process of winebus.sys crashes on a keypress from the keyboard.

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52101

--- Comment #1 from Ivo Ivanov  ---
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

[Bug 52101] The winebus.sys process crashes in lnxev mode when a keyboard key is pressed.

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52101

Ivo Ivanov  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. |

[Bug 52101] The winebus.sys process crashes in lnxev mode when a keyboard key is pressed.

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52101

--- Comment #2 from Rémi Bernon  ---
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).

[Bug 52101] The winebus.sys process crashes in lnxev mode when a keyboard key is pressed.

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52101

--- Comment #3 from Ivo Ivanov  ---
(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".