PORTS Forum
Ports and Interfaces => USB => Topic started by: ulao on December 07, 2017, 08:55:27 am
-
I have this monster descriptor (that works) that I need to add one more piece too. It's too big for this forum.
https://pastebin.com/kBpV9Ld1
In that example I added the extra part as a dual device but this is causing a bug in windows.
The part I'm adding is at the end looks like this
//api
0x06, 0x00, 0xff,
0x09, 0x01, // USAGE (Vendor Usage 1)
0xa1, 0x01, // COLLECTION (Application)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255)
0x75, 0x08, // REPORT_SIZE (8)
//generic (64 size) - good speed coudl always make a smaller packet
//get
0x85, 0x11, // REPORT_ID (17)
0x95, 0x20, // REPORT_COUNT (64)
0x09, 0x00, // USAGE (Undefined)
0xb2, 0x02, 0x01, // FEATURE (Data,Var,Abs,Buf)
//send
0x85, 0x12, // REPORT_ID (18)
0x95, 0x44, // REPORT_COUNT (68) 64+(rid,command, 0, 0)
0x09, 0x00, // USAGE (Undefined)
0xb2, 0x02, 0x01, // FEATURE (Data,Var,Abs,Buf)
//LDC DC
//get
0x85, 0x13, // REPORT_ID (19)
0x95, 0xc0, // REPORT_COUNT (192)
0x09, 0x00, // USAGE (Undefined)
0xb2, 0x02, 0x01, // FEATURE (Data,Var,Abs,Buf)
//send
0x85, 0x14, // REPORT_ID (20)
0x95, 0xc4, // REPORT_COUNT (196) 192+(rid,command, 0, 0)
0x09, 0x00, // USAGE (Undefined)
0xb2, 0x02, 0x01, // FEATURE (Data,Var,Abs,Buf)
0xc0, // END_COLLECTION
When doing this windows lists this device twice in the game controller list. Causing mayhem on the OS. If I put this section in side the first report windows is happy but linux gets all mad.
example.
https://pastebin.com/NCSP6WJ1
I guess I prefer the second one but where can I put this "api" as I call it so that it does not cause issues.
-
It look like you want to add four Feature reports either within your existing collection or as a second collection?
You could try this:
http://eleccelerator.com/usbdescreqparser/
In Windows, be sure to uninstall the current device before reattaching with new descriptors.
-
yeah definitely removing drivers. The parser seems to like it both ways. Windows likes it with in the same collection but something about linux does not. When I keep it separate windows has a bug but linux likes it. Very strange bug. I'll play with the parser a bit and see if I can make it work.
it's not really two collections, its more like two devices. Normally when I make two Usage Page's like that I get two device. For example a mouse and a keyboard. In this case its a gamepad and a hid generic. For some reason windows thinks I have two joysticks. (second example I pasted). In the first example I put all collections under the gamepad device. That works fine in widows but causes issue in linux. I'm not really sure why.
-
Each top-level application collection defines a HID function/device. See 6.2.2.6 in the HID spec.
-
I'm was able to figure out the issue on the linux side
0x75,0x08, // Report Size 1
0x95,0x20, // Report Count 1
My size Is apparently too big. If I change to 0x95,0x05, its fine.
So I guess I need to keep things as two devices and fix this windows bug. I tried to capture this in an image. Moving that section out of the main usage creates duplicate controllers.
-
Ok so now I see what it is doing but this is far past my knowledge. In short it is creating multiple device instances. When I dynamically change the PID. See attached.
So what do I mean by dynamically changing PID....
My device holds an ID in eeprom. When the device is ran it dynamically alters the PID based on the eeprom value. This way each device ( I have 4) is od04, odo5, odo6, or odo7. I need to do this to get the controllers to remain in order from 1,2,3 to 4. When the name is changed windows messes up the device instance apparently. Only way to fix this is by manually editing the registry.
The issue is that this only happens with this dual device style report. but being linux is having issues with report sizes I have no choice but to use this. I wonder if I can change the usage type to prevent this?
-
After much hardship I was able to fix the issues in c# by delete the registry conflicts.
-
Thanks for reporting back; sorry you had to suffer!
-
It's probably too late to help, but I couldn't resist running your massive report descriptor through my home grown HID report decoder (https://sourceforge.net/projects/hidrdd/) - also on github (https://github.com/abend0c1/hidrdd) - free and open source ;D.
It shows up a few errors (search for "<-- Error:") which may cause the parsers on various operating systems to get confused:
https://pastebin.com/WxdgtGRq ...madness decoded (1365 bytes)
Below is a cleaned up version that is considerably smaller although I can't guarantee that it is any better:
https://pastebin.com/UhSRyTHH ...madness fixed (1022 bytes)
-
"In Windows, be sure to uninstall the current device before reattaching with new descriptors."
So this may be the cause of pain I was experiencing - when developing my I2C HID device, I would *disable* and re-enable the device through control panel when I changed the firmware, to have Windows re-enumerate. This was fine when changing behavior of the device. But was this not sufficient when changing descriptors? I was having problems with Windows not giving me the proper input buffer size in it's CAPS structure. At some point I rebooted for another reason, and I believe this coincided with the input buffer size showing up correctly.
I didn't see this documented anywhere, but this may be the kind of thing you learn from experience - I guess "uninstall" is necessary when changing descriptors, even though "disable" + "enable" causes it to re-read the descriptors on enumeration?
-
I always use uninstall. This Windows behavior is the source of much developer frustration!