Opened 6 years ago
Last modified 4 years ago
#15051 new bug
USB Mouse not working on hrev53104
Reported by: | MelanieFox | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/Input/HID/USB | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86-64 |
Description
I have a 5 Button USB Gaming Mouse. 1ea7:1006 /dev/bus/usb/0/5 "SHARKOON Technologies GmbH" "" ver. 0104
The device is unreponsive. Mouse Pointer is not moving neither does any of the buttons trigger some reaction.
According to listusb -v the Device has to Interfaces in one configuration. One Interface is reporting as Mouse and the other one as keyboard.
When i disconnect the USB Gaming Mouse the Keyboard also stops working. All three leds on the Keyboard than flash every few seconds. (seems like reinit...)
Attaching listusb and -v output, also syslog.
Attachments (8)
Change History (16)
by , 6 years ago
Attachment: | syslog.txt added |
---|
by , 6 years ago
Attachment: | usb_device_list.txt added |
---|
by , 6 years ago
Attachment: | usb_device_list_long.txt added |
---|
comment:1 by , 6 years ago
comment:2 by , 6 years ago
We already have facilities for device specific init and creating custom report descriptors. See https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/input/usb_hid/QuirkyDevices.cpp
comment:3 by , 6 years ago
What i found out so far:
My Mouse is handled by hid-generic under linux
The Report Descriptor seen by Haiku differs from the one linux reports.
I've tried to code a quirk by reporting the linux one.
Hasn't fixed the issue but looked much better than before.
Oddly the xhci driver reports a TRB not found.
Seems like the device is stuck and doesn't generates any events at all.
What i will try next is the kernel go panic when that not found TRB message occurs, with usb trave and usb hid trace enabled.
Will attach some files with the report descriptors from haiku and linux (hexed) tomorrow.
by , 6 years ago
Attachment: | decus_report_decoded_linux added |
---|
comment:4 by , 6 years ago
I've found a way to finally get her running. My solution involves a patched rdesc and a dirty little hack in HIDDevice.cpp (don't know how to solve this otherwise :/ )
Attaching modified sources...
by , 6 years ago
Attachment: | QuirkyDevices.cpp added |
---|
comment:5 by , 6 years ago
Could you please attach a patch wiki:CodingGuidelines/SubmittingPatches#Submittingyourcommits instead of modified sources here. Thanks!
comment:7 by , 5 years ago
Hi,
I looked at the descriptors you attached. Strangely enough, the one marked "Haiku" is different only in the first 32 bytes, and only for a nibble each time (either the top 4 or bottom 4 bits of a byte, but never both at the same time). This affects exactly 16 bytes of the report.
This does not match with the Linux quirks that you linked, and they refer to a different set of USB IDs, so they would not be used for your mouse, how did you come to the conclusion that these were related?
Since this vendor ID is apparently not referred to anywhere in Linux sources, it's more likely that the HID descriptor was somehow corrupt in Haiku, maybe because of a broken USB driver at a lower level.
comment:8 by , 4 years ago
Found this source. But as you say can't find it anywhere else.
It appears this mouse has a broken report descriptor: https://github.com/torvalds/linux/blob/master/drivers/hid/hid-holtek-mouse.c
We may need to add a patching facility to our USBHID driver.