[Sorry about the delay, I was offline last week.]
> 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've seen that bit; it's what caused me to think about Ordinal usages in the
first place :-) (If you have multiple "Dial" usages, at the moment the first
one will be mapped to REL_DIAL, the others to codes which have nothing to do
with dials.)
In the meantime, I've mangled my kernel enough to let me receive REL_DIAL_x
events from my device. I'm using a USB Report Descriptor with a structure
like this:
Usage (Generic Desktop/Multi Axis Controller)
Collection (Application)
Usage (Generic Desktop/Dial)
Collection (Logical)
Usage Page (Ordinal)
Usage Minimum (1)
Usage Maximum (9)
Report Count (9)
Report Size (8)
Input (Variable, Relative)
End Collection
End Collection
As far as I understand the HID specification, this is valid (I might be wrong!)
Bye,
Jens.
--
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]
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
