Giter Club home page Giter Club logo

abend0c1 / hidrdd Goto Github PK

View Code? Open in Web Editor NEW
91.0 6.0 14.0 848 KB

USB Human Interface Device (HID) Report Descriptor Decoder. This will convert a binary or printable hex report descriptor into a C header file. The printable hex can, for example, be an existing C header file - so it can be used to mechanically document an existing report descriptor declaration. The binary report descriptor could, for example, have been extracted from a Wireshark trace of a USB device handshake.

REXX 100.00%
rexx hid report descriptor decoder usb human-interface-device hid-report-descriptor

hidrdd's Introduction

RDD! icon

RDD! HID Report Descriptor Decoder

This will read a USB Human Interface Device (HID) report descriptor from the specified input file then attempt to decode it and, optionally, create a C language header file from it. It also does some minimal sanity checks to verify that the report descriptor is valid. The input file can be a binary file or a text file (for example, an existing C header file). If it is a text file, it will concatenate all the printable-hex-like text that it finds on each line (until the first non-hex sequence is found) into a single string of hex digits, and then attempt to decode that string. You can feed it an existing C header file and it will decode it as long as you have all the hex strings (e.g. 0x0F, 0x0Fb2) at the beginning of each line. Commas (,) and semicolons (;) are ignored. Specify the --right option if the hex strings are on the rightmost side of each line.

Features

  • Decodes all the USB HID descriptors currently published by usb.org
  • Converts HID Report Descriptor into C language structure declarations
  • Highlights common errors such as redundant descriptor tags, field size errors etc
  • Accepts binary or textual input (for example existing C structure definitions)
  • Decodes vendor-specific descriptors (if you supply a simple definition file)

Usage

  rexx rd.rex [-h format] [-i fileinc] [-o fileout] [-dsvxb] -f filein

Or:

  rexx rd.rex [-h format] [-i fileinc] [-o fileout] [-dsvx]  -c hex

Where:

  filein           = Input file path to be decoded
  fileout          = Output file (default is console)
  fileinc          = Include file of PAGE/USAGE definitions
  hex              = Printable hex to be decoded from command line
  format           = Type of output C header file format:
                     AVR    - AVR style
                     MIKROC - MikroElektronika mikroC Pro for PIC style
                     MCHIP  - Microchip C18 style
  -f --file        = Read input from the specified file
  -c --hex         = Read hex input from command line
  -r --right       = Read hex input from the rightmost side of each line
  -b --binary      = Input file is binary (not text)
  -o --output      = Write output to the specified file (default is console)
  -s --struct      = Output C structure declarations (default).
                     Note: You must direct your compiler to pack these structures
  -d --decode      = Output decoded report descriptor
  -h --header      = Output C header in AVR, MIKROC or MICROCHIP format
  -x --dump        = Output hex dump of report descriptor
  -a --all         = Output all valid array indices and usages
  -i --include     = Read vendor-specific definition file
  -v --verbose     = Output more detail
  --version        = Display version and exit
  -? --help        = Display this information
  -vv              = Modifies --all so that even array field indices that
                     have blank usage descriptions are listed

Prerequisites

You need a REXX interpreter installed, such as

  1. Regina REXX
  2. Open Object REXX

Examples

rexx rd.rex -d --hex 05010906 A1010508 19012903 15002501 75019503 91029505 9101 C0
...decodes the given hex string. Spaces are not significant

rexx rd.rex -sc 05010906 A1010508 19012903 15002501 75019503 91029505 9101 C0
...generates C structure declarations for the given hex string

rexx rd.rex -d -f myinputfile.h -o myoutputfile.txt
...decodes the hex strings found in myinputfile.h into myoutputfile.txt

rexx rd.rex myinputfile.h
...generates C structure declarations for the hex strings found in myinputfile.h

rexx rd.rex --include mybuttonmap.txt -f myinputfile.h
...generates C structure declarations for the hex strings found in myinputfile.h 
using vendor-defined usages defined in mybuttonmap.txt

rexx rd.rex -dr usblyzer.txt
...decodes the hex strings found on the rightmost side of each line of the
usblyzer.txt input file

Configuration File Format

The configuration file (rd.conf) format is identical to the Include File Format shown below. It contains the approximately 3000 known usages that are documented by usb.org. The maximum number of usages is 4294967296 so it makes sense to store the small number of known ones in a single file. However, if you have vendor-defined usages then you may want to include the definitions for them using an "include" file...

Include File Format

Vendor usages can be defined in a separate file which will be automatically loaded if you name it pppp.conf - where pppp is the hex vendor usage page number. You can name it anything you like, but if you do that you will have to explicitly include it by coding "--include your.special.usages" on the command line.

See FFA0-Plantronics.txt for an example. This example file would be automatically loaded if it was named FFA0.conf.

Each USB HID Usage code is a 4 byte value comprising a 2 byte Usage Page and a 2 byte Usage within that page. Vendor-specific usages must have a Usage Page code in the range 0xFF00 to 0xFFFF. Within each Usage Page, there can be up to 65536 usages (from 0x0000 to 0xFFFF). The official USB HID Usage Tables specification defines usages for almost everything imaginable - including parts of the human body...although, strangely, it stops short of defining usages for any of the naughty bits. If you need to define a usage for naughty bits, then a vendor-specific usage page is the place to do it.

The --include file contains the following lines of comma-separated values...

  • One line describing the the vendor-specific usage page:

    • pppp - The vendor-specific Usage Page in hex (FF00 to FFFF)
    • vendordesc - A short description of the vendor and product
    • vendorprefix - A very short (few letters) abbreviation of the vendor and product which is used as a prefix on any generated C language variable names
  • One line for each usage within the vendor-specific page:

    • ppppuuuu - The explicit usage number comprising the vendor page number (pppp) in hex and usage number (uuuu) in hex.

    • usagedesc - A short description of the usage

    • usagetype - Optional: An abbreviation of the type of the usage. The following usage types are currently documented in the usb.org documents:

      Controls:
      LC Linear Control
      MC Momentary Control
      OOC On/Off Control
      OSC One Shot Control
      RTC Re-trigger Control
      Collections:
      CA Application Collection
      CL Logical Collection
      CP Physical Collection
      CR Report Collection
      NAry Named Array Logical Collection
      UM Usage Modifier Logical Collection
      US Usage Switch Logical Collection
      Data:
      BB Buffered Bytes
      DF Dynamic Flag
      DV Dynamic Value
      Sel Selector
      SF Static Flag
      SV Static Value
    • usageshortname - Optional: A short name of the usage which is used in any generated C language variable names. Normally camel-case names are generated from the "usagedesc", for example, "System Speaker Mute" would be translated to variable name "SystemSpeakerMute", but if you want to specify a different short name, for example, "Mute", then you can define it here.

  • Blank lines are ignored, as is any line that does not begin with a hexadecimal number (pppp or ppppuuuu).

The include file should look like this:

    // A usage page definition line should precede one or more usages in that page:
    pppp pagedesc,vendorprefix

    // Each usage line is identified by a hexadecimal usage number (ppppuuuu):
    ppppuuuu usagedesc,usagetype[,usageshortname]
    .
    .
    .
    ppppuuuu usagedesc,usagetype[,usageshortname]

hidrdd's People

Contributors

abend0c1 avatar nbriggs avatar thomaskuehne avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

hidrdd's Issues

Extract HID Usage definitions from a PDF/JSON spec

I noted this text on https://www.usb.org/hid page:

The HID Usage Tables 1.3 document also includes all Usage definitions as a JSON file as an attachment to the PDF. The PDF serves as the 'single' source of truth.

And https://usb.org/sites/default/files/hut1_3_0.pdf have indeed HidUsageTables.json attached.
Waratah tool used by USB-IF HID-WG committee have code that extracts that JSON and using it directly.

Maybe RDD! could have such code too instead (in addition to) of manually maintaining rd.conf file?

Contradicting data in rd.rex

k.0UNIT.0000E121 = 'Energy in joules [0.1 μJ units],-7 J'
k.0UNIT.0000E121 = 'Moment of force in newton metres [0.1 μN m units],-7 N m'
k.0UNIT.0000E121 = 'Surface tension in newton per metre [1 g/s² units],-3 kg/s²'
three times the same value for 3 different things ?

k.0UNIT.010000E1 = 'Luminance [1 cd/cm² units],4 cd/m²'
is assigned twice

Missing Pages

Please add the following two usage pages to the *.conf files:

0080.conf:

PAGE 80 Monitor
01 Monitor Control
02 EDID Information
03 VDIF Information
04 VESA Version

// -------------------------------------------------------

0082.conf:

PAGE 82 VESA Virtual Control
01 Degauss
10 Brightness
12 Contrast
16 Red Video Gain
18 Green Video Gain
1A Blue Video Gain
1C Focus
20 Horizontal Position
22 Horizontal Size
24 Horizontal Pincushion
26 Horizontal Pincushion Balance
28 Horizontal Misconvergence
2A Horizontal Linearity
2C Horizontal Linearity Balance
30 Vertical Position
32 Vertical Size
34 Vertical Pincushion
36 Vertical Pincushion Balance
38 Vertical Misconvergence
3A Vertical Linearity
3C Vertical Linearity Balance
40 Parallelogram Distortion
42 Trapezoidal Distortion
44 Tilt
46 Top Corner Distortion Control
48 Top Corner Distortion Balance
4A Bottom Corner Distortion Control
4C Bottom Corner Distortion Balance
56 Horizontal Moiré
58 Vertical Moiré
5E Input Level Select
60 Input Source Select
6C Red Video Black Level
6E Green Video Black Level
70 Blue Video Black Level
A2 Auto Size Center
A4 Polarity Horizontal Synchronization
A6 Polarity Vertical Synchronization
A8 Synchronization Type
AA Screen Orientation
AC Horizontal Frequency
AE Vertical Frequency
B0 Settings
CA On Screen Display
D4 Stereo Mode

C structures padding is not considered

Th C file output may be missleading, for example UPS device:

typedef struct
{
  uint8_t  reportId;                                 // Report ID = 0x15 (21)
                                                     // Collection: CA:UPS CP:Output
  int16_t  POW_UPSOutputDelayBeforeShutdown;         // Usage 0x00840057: Delay Before Shutdown, Value = -1 to 32767, Physical = ((Value + 1) x 60 - 60) in s
} featureReport15_t;

This struct (in most common platforms) is of 4 bytes size (1 byte report ID + 1 byte padding + 2 bytes value). It can't be used to serialize the report, because report's doesn't expect any padding. One can enable compiler-specific structure packing mode, but at least warning in documentation should be noted.

Wrong calculations in rd.rex

I checked all your units that can be found here:
https://www.unc.edu/~rowlett/units/siderive.html

As far as I see they are correct with 2 exceptions:
k.0UNIT.0000F002 = 'Angular velocity [1 rad/s units],0 rad/s'
k.0UNIT.0000E002 = 'Angular acceleration [1 rad/s² units],0 rad/s²'
are wrong.

Correct would be:
k.0UNIT.0000F012 = 'Angular velocity [1 rad/s units],0 rad/s'
k.0UNIT.0000E012 = 'Angular acceleration [1 rad/s² units],0 rad/s²'

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.