Ports and Interfaces > USB

descriptor madness.

<< < (2/3) > >>

ulao:
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?

ulao:
After much hardship I was able to fix the issues in c# by delete the registry conflicts.

Jan Axelson:
Thanks for reporting back; sorry you had to suffer!

android:
It's probably too late to help, but I couldn't resist running your massive report descriptor through my home grown HID report decoder - also on github - 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)

yumbrad:
"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?

Navigation

[0] Message Index

[#] Next page

[*] Previous page