Author Topic: descriptor madness.  (Read 14591 times)

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
descriptor madness.
« 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
Code: [Select]
  //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.
 
« Last Edit: December 07, 2017, 11:38:34 am by ulao »

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: descriptor madness.
« Reply #1 on: December 07, 2017, 12:50:09 pm »
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.

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
Re: descriptor madness.
« Reply #2 on: December 07, 2017, 02:45:08 pm »
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.
« Last Edit: December 07, 2017, 02:50:18 pm by ulao »

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: descriptor madness.
« Reply #3 on: December 07, 2017, 08:10:00 pm »
Each top-level application collection defines a HID function/device. See 6.2.2.6 in the HID spec.

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
Re: descriptor madness.
« Reply #4 on: December 07, 2017, 08:49:46 pm »
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.
« Last Edit: December 07, 2017, 09:04:18 pm by ulao »

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
Re: descriptor madness.
« Reply #5 on: December 07, 2017, 09:16:08 pm »
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?
« Last Edit: December 07, 2017, 09:17:51 pm by ulao »

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
Re: descriptor madness.
« Reply #6 on: December 07, 2017, 10:53:08 pm »
After much hardship I was able to fix the issues in c# by delete the registry conflicts.

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: descriptor madness.
« Reply #7 on: December 08, 2017, 08:39:20 pm »
Thanks for reporting back; sorry you had to suffer!

android

  • Member
  • ***
  • Posts: 5
Re: descriptor madness.
« Reply #8 on: March 15, 2018, 08:13:09 am »
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

  • Member
  • ***
  • Posts: 1
Re: descriptor madness.
« Reply #9 on: March 15, 2018, 01:07:43 pm »
"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?

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: descriptor madness.
« Reply #10 on: March 16, 2018, 09:19:40 am »
I always use uninstall. This Windows behavior is the source of much developer frustration!