Re: [linux-usb-devel] [RFC] HID bus design overview.

Robert Marquardt
2007-04-02T10:14:10Z

Jiri Kosina wrote:

> I agree. I am aware of devices for which just inspecting the parsed data
> would be OK (some keyboards with usage mappings which are not defined by
> HUT, for example), but also of devices which require special handling on
> the report level - Robert Marquardt pointed me in a private mail to a few
> devices which are broken par-excellence, and for which handling on report
> level would be convenient.
>
> Also, handling on report level would be nice to have so that we could hook
> a hidraw driver to it.

Just forgot to use "Reply All".

Here is the text (expanded):
Definitely. I know of several devices where the HID descriptor and the
data sent completely disagree.
A Metex USB Multimeter for example tells that it has a 4 byte report
divided into a 3 byte and a 1 byte element. The device sends two reports
each containing two 2 byte elements with one in the second report not
containing data.
The wierdest device is a CD archive torus which shows up as a simple
standard mouse. Commands are sent by *reading* strings.
The Office Rocket Launcher is posing as a keyboard and reacts to the
LEDs being set (this is of interest for the Num-Lock thread here).
I definitely hope that the latter two devices will never get official
kernel support in any way.

Why is the report parsed on driver level at all? It should be possible
to allow drivers to manipulate the reports, but i see no reason to split
the report into usages that early. The Windows HID API parses the report
happily in the HID.DLL for user programs. Drivers have the same API
available on kernel level.
So a raw API for the drivers should be the primary API. It is usually
easier to manipulate the report directly instead of abstract operations.
It is also fairly safe. The device has been identified so the offending
report layout can be presumed. Parsing for specific usages should be
done from the driver. Preparsing the report before the data is handed to
the driver only wastes CPU cycles.