Hey, Greg.
I went ahead and started implementing the changes in libusb as per your recommendation. But I'm following up cause you asked about the usbhid-dump output.
> But this really is not a HID device, right?
Well, Windows does decide to recognize it as a HID device. I captured some packets send to the device's control endpoint of unknown transfer type with URB function: URB Function: URB_FUNCTION_GET_MS_FEATURE_DESCRIPTOR (0x002a). Perhaps that has something to do with this as my research says that MS OS Descriptors indicate which driver Windows should use.
> What is the HID descriptor that it prints out? Can you use the
> 'usbhid-dump' program that is part of the usbutils package to show the
> report descriptors?
usbhid-dump unfortunately wouldn't dump the endpoint of the device, even in my test environment with the changes I made to the kernel. iface_list.c:140 shows that usbhid-dump also checks for an INTERRUPT IN endpoint.
However, via Wireshark, I grabbed the HID descriptor for that endpoint and here are the results:
0000 06 90 ff 0a 00 ff a1 01 15 00 26 ff 00 75 08 95
0010 40 09 02 81 02 09 03 91 02 0a 00 ff b1 02 c0
HID Report
Usage Page (Vendor)
Header
Usage Page: Vendor (0xff90)
Usage (Vendor)
Header
Usage: Vendor (0xff)
Collection (Application)
Header
Collection type: Application (0x01)
Logical Minimum (0)
Logical Maximum (255)
Report Size (8)
Report Count (64)
Usage (Vendor)
Input (Data,Var,Abs)
Usage (Vendor)
Output (Data,Var,Abs)
Usage (Vendor)
Feature (Data,Var,Abs)
End Collection
No pressure for a quick response. Things are going quite smoothly with libusb in OpenRGB, so your help isn't imperative for this.
Thanks again :)
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
