Getting HID report descriptors

[spiff]

I am playing around with some simple USB HID game devices. Hardware es essentially the same as my C64 USB keyboard.

1) Is there some tool that can show the HID report descriptor received when plugging in a device? I would like to use this to examine the report descriptor of some commercial HID devices (game-pads, joysticks, etc.) to get some better understanding of the HID report descriptor. Tool should run on either Windows XP or Linux.

2) What is the most simple report descriptor for a two-axis digital joystick with one button? (old C64/Atari joystick). I looked at the Atari style joystick/controller to USB adapter by Raphaël Assénat, but this seems much more complicated than what I need.

3) If I want to have two joysticks connected to one controller, would you suggest a single report defining four different axis, or should this be done as two (identical) reports (one for each joystick)? I see that most multi-axis joysticks define the X and Y axis and the throttle and rudder. But ideally my setup has two X-axes and two Y-axis (one of each for each joystick). And also one button for each joystick.

[Grendel]

I am playing around with some simple USB HID game devices. Hardware es essentially the same as my C64 USB keyboard.

1) Is there some tool that can show the HID report descriptor received when plugging in a device? I would like to use this to examine the report descriptor of some commercial HID devices (game-pads, joysticks, etc.) to get some better understanding of the HID report descriptor. Tool should run on either Windows XP or Linux.

I used USBsnoop for that. My experience w/ the commercial devices I looked at is that the developers had a hard time w/ the USB specs I ended up reading the specs very carefully and came up w/ a fairly complex yet compact descriptor for the 3DP-Vert converter.

2) What is the most simple report descriptor for a two-axis digital joystick with one button? (old C64/Atari joystick). I looked at the Atari style joystick/controller to USB adapter by Raphaël Assénat, but this seems much more complicated than what I need.

I would do something like this:

Code: Select all

USAGE_PAGE (Generic Desktop)
USAGE (Joystick)
COLLECTION (Application)
   USAGE (Pointer)
   COLLECTION (Physical)
     REPORT_COUNT (2)
     REPORT_SIZE (8)
     LOGICAL_MINIMUM (-128)
     LOGICAL_MAXIMUM (127)
     PHYSICAL_MINIMUM (0)
     PHYSICAL_MAXIMUM (255)
     USAGE_PAGE (Generic Desktop)
     USAGE (X)
     USAGE (Y)
     INPUT (Data,Var,Abs)
     REPORT_COUNT (1)
     REPORT_SIZE (1)
     LOGICAL_MINIMUM (0)
     LOGICAL_MAXIMUM (1)
     PHYSICAL_MAXIMUM (1)
     USAGE_PAGE (Button)
     USAGE_MINIMUM (Button 1)
     USAGE_MAXIMUM (Button 1)
     INPUT (Data,Var,Abs)
   END_COLLECTION
   REPORT_SIZE (7)
   INPUT (Cnst,Ary,Abs)
END_COLLECTION

3) If I want to have two joysticks connected to one controller, would you suggest a single report defining four different axis, or should this be done as two (identical) reports (one for each joystick)? I see that most multi-axis joysticks define the X and Y axis and the throttle and rudder. But ideally my setup has two X-axes and two Y-axis (one of each for each joystick). And also one button for each joystick.

Good question, I don't know if you can have two X/Y USAGEs in one report descriptor. Time to read the USB docs I'd say

[spiff]

Thanks for the reply.

I used USBsnoop for that. My experience w/ the commercial devices I looked at is that the developers had a hard time w/ the USB specs I ended up reading the specs very carefully and came up w/ a fairly complex yet compact descriptor for the 3DP-Vert converter.

I tried USBsnoop and was able to extract some report descriptors from USB gameport device. It has a switch with four different modes, and I suppose each one gives a different report descriptor. Now I'm trying to "decipher" it (by re-creating the descriptors in the HID report descriptor tool), but it seems you are right: the report descriptors seem quite complex, and not optimal at all. Still, I think this exercise will give me a somewhat better understanding of what I need for my report descriptor.

Code: Select all

USAGE_PAGE (Generic Desktop)
USAGE (Joystick)
COLLECTION (Application)
   USAGE (Pointer)
   COLLECTION (Physical)
     REPORT_COUNT (2)
     REPORT_SIZE (8)
     LOGICAL_MINIMUM (-128)
     LOGICAL_MAXIMUM (127)
     PHYSICAL_MINIMUM (0)
     PHYSICAL_MAXIMUM (255)
     USAGE_PAGE (Generic Desktop)
     USAGE (X)
     USAGE (Y)
     INPUT (Data,Var,Abs)
     REPORT_COUNT (1)
     REPORT_SIZE (1)
     LOGICAL_MINIMUM (0)
     LOGICAL_MAXIMUM (1)
     PHYSICAL_MAXIMUM (1)
     USAGE_PAGE (Button)
     USAGE_MINIMUM (Button 1)
     USAGE_MAXIMUM (Button 1)
     INPUT (Data,Var,Abs)
   END_COLLECTION
   REPORT_SIZE (7)
   INPUT (Cnst,Ary,Abs)
END_COLLECTION

Thanks. I'll try that first, and then perhaps modify it to better suit my needs along the way. Since I'm using digital joysticks, I guess the range of the X- and Y-axis should be -1 to 1? In fact, perhaps this should be considered a gamepad, not a joystick, but I guess the difference is mostly the physical appearance, and this is indeed a joystick, just not with analogue axes.

Good question, I don't know if you can have two X/Y USAGEs in one report descriptor. Time to read the USB docs I'd say

Ahh. I was hoping someone had already done the hard work of finding out. I guess I better start reading

[spiff]

I tried USBsnoop and was able to extract some report descriptors from USB gameport device. It has a switch with four different modes, and I suppose each one gives a different report descriptor. Now I'm trying to "decipher" it (by re-creating the descriptors in the HID report descriptor tool), but it seems you are right: the report descriptors seem quite complex, and not optimal at all. Still, I think this exercise will give me a somewhat better understanding of what I need for my report descriptor.

Turned out the four report descriptors were identical, so the position of the switch determines how each axis is mapped in the HID report.

After deciphering the report descriptor it turns out that it is not that bad, although if I have understood the specs correctly, there are a few redundant entries in the descriptor. On the other hand, I suppose that makes it somewhat more readable.

Now it seems to be time to do some reading of the specs