Author Topic: descriptor madness.  (Read 48 times)

ulao

  • Frequent Contributor
  • ****
  • Posts: 83
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: 2625
    • 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: 83
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: 2625
    • 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: 83
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: 83
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: 83
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: 2625
    • Lakeview Research
Re: descriptor madness.
« Reply #7 on: December 08, 2017, 08:39:20 pm »
Thanks for reporting back; sorry you had to suffer!