[This is rather esoteric and probably not of general interest, but since an
implementation would affect the USB code, I'm CC:ing the linux-usb-devel
mailing list.]
I'm currently retrofitting an old HP "dial box"[1] with a USB interface. This
is a nice little box with 9 rotary encoders, intended for use with CAD and
graphics applications. The HP box is probably no longer produced, but there
are similar devices with 8 dials from other manufacturers.
In USB HID terms, this device most closely matches the "Multi-Axis Controller"
application usage[2]. Unfortunately, the writers of the Usage Tables document
seem to have been fixed on "Spaceball" or "Spacemouse" devices, which have
6 degrees of freedom (not 8 or 9) and where a definite orientation (X/Y/Z)
or axis (Rx/Ry/Rz) usage can be assigned to each control in the device.
For a dialbox, it would be better to let the application (or even the user)
decide which control performs which function (e.g., translation, rotation,
viewpoint or even color/volume/etc.).
As far as I can see, the only way to create an HID compliant report descriptor
for such a device is to use the "Ordinal" usage page to specify 9 instances
of a "Dial" control. Unfortunately, the Linux USB/input drivers don't support
the Ordinal page at the moment. I therefore propose to add support for this
page to the hid-input driver and to somehow extend the /dev/input... driver to
make use of this information.
It would be highly desirable to keep the interfaces (both on the USB side
and the input device side) backwards compatible, so that (1) any USB device
which doesn't use the Ordinal page would produce exactly the same input
events as before, and (2) any existing application which uses input devices
would be usable without recompilation. I see two ways to achieve this:
1. Encode (in some fashion) the instance information in unused space in the
input_event structure. The "type" member of that structure is an
"unsigned short", but only 5 bits of it are currently in use (as far as
I can tell).
2. Define a new type of input event to indicate a control instance, and send
it in front of the actual input events for that control. Example:
Where a "normal" dial would send an event with type=EV_REL, code=REL_DIAL;
a dial with multiple instances would send *two* events (the hypothetical
type=EV_INSTANCE/value=instance# plus the original event).
Of these approaches, (1) has a lower overhead and (2) is cleaner (the instance
information doesn't really belong into any of the existing members of
struct input_event). I'd prefer (2) because I don't think that the small
performance hit would be critical (these are *Human Interface Devices*; humans
are s.l.o.w.)
Please let me know what you think of this proposal; if it's acceptable, I'll
volunteer to actually implement it :-)
Greetings,
Jens.
[1] Originally it had a "HIL" interface, which is an HP proprietary serial
loop that predates USB and is quite obsolete.
[2] See the HID class spec. resp. the HID Usage Tables spec., version 1.11
--
mailto:[EMAIL PROTECTED] phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
