> > 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).
>
> No, we can't, if we want to keep a fixed mapping from HID usage codes to
> input_event.code values (of course, that is itself something that could be
> changed, but there remains still the problem of using a bitmap to represent
> expected events).
We don't necessarily have a fixed mapping from HID usages to Input
codes.
Note this bit in hid-input.c:
while (usage->code <= max && test_and_set_bit(usage->code, bit))
usage->code = find_next_zero_bit(bit, max + 1, usage->code);
If the code the switch() statement would select is already occupied,
the following one is used. So there is no problem with having a "Dial"
USB HID usage select REL_DIAL0, and have it followed with REL_DIAL1,
etc. Any other scheme is also OK - the HID->input mapping code will
always be a mess anyway.
> I can easily imagine other devices for which multiple instances of a single
> usage are needed - say, an audio mixer with N "Slider" controls. Until now
> I hoped that we could come up with a general way to handle such things,
> instead of introducing special cases (REL_DIALx, REL_SLIDERx, REL_FOOx ...
> for each.
Most devices don't have N generic controls. They're usually marked
somehow and that's why in 99% of cases making a define for each is the
right way.
> > 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.
>
> That may be possible (I'll have to see if it requires changes to the HID
> driver), but would complicated life in user space.
It'd need changes in the HID driver, and for userspace it wouldn't be
much too hard, but this really only makes sense for devices with a very
high number of controls.
--
Vojtech Pavlik
SuSE Labs
_______________________________________________________________
Hundreds of nodes, one monster rendering program.
Now that's a super model! Visit http://clustering.foundries.sf.net/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
