Jens Kilian wrote: > [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). >
What about: 3. type = EV_REL, code=REL_DIAL8 value=1234 for the 8th dial turned 1234 units in the positive direction ? Or did I miss something ? 1. uses type for something it was not designed for. 2. is not too appealing. If we follow your way, we'll soon have people asking to combine events in complicated ways. With your method, interpretation of events depends on some context (the previous events), and that's hopefully not necessary. > 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.) What is an instance ? As I understand it, it's just the number of an axis in the range [0..8]. If available axes are not enough, we can add new ones (REL_DIAL0 to REL_DIALn, with n almost as big as you want). We have plenty of room (16 bits on 32-bits intel cpus). I see a 4th solution, perhaps useful for weird dial-boxes having many thousands of dials (is that possible ?): register as many input devices as necessary. I guess it would be possible to have one physical device seen as several input devices. > > 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 -- Johann Deneux _______________________________________________________________ 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
