https://bugs.winehq.org/show_bug.cgi?id=52101
--- Comment #3 from Ivo Ivanov logos128@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".