Array elements work as their name suggests. The values issued by the
report are considered indexes. Typically, when working with usage
ranges, you want the usage min/max to match the logical min/max.
Since the usage min is off by one, this explains why pressing an
'A' (0x4) causes a 'B' (0x5) usage/keystroke to be generated.
The Mac OS X HID stack requires that devices strictly adhere to the
HID spec. You can compensate for older device by creating an
interface driver that subclasses the IOUSBHIDDriver and patches the
report descriptor.
As for the mouse, the descriptor seems to be OK, but without
witnessing first hand what is happening, I'm not sure what might be
going wrong.
- Rob
On Nov 24, 2005, at 12:20 PM, E Howard wrote:
I have a special purpose mouse which seems to work correctly on
Windows but which exhibits some unexpected behavior on OSX.
This device is primarily a pointing device with a number of extra
buttons. The buttons can manifest as either mouse actions (left
button, right button, etc.) or keyboard actions, including
modifiers. The device acquires both mouse and keyboard
functionality not with two separate USB Interfaces, but with one
USB HID Interface (see the USB Descriptors below) by using the USB
HID ReportID mechanism. Based on the USB Interface Protocol and
Subclass, the Interface is a Boot Protocol Mouse.
The second USB Interface in the device is used for special
configuration data.
The mouse tracking seems to work correctly.
All of the Mouse Buttons seem to map onto the Right Button in OSX,
which means no Left Mouse Button -- making the device essentially
useless as a mouse. (For example the "Left" button produces the
HID report: 4d 01 00 00 00 00 00 00 (4d is the ReportID) but the
Right button action)
The Keyboard actions are unusual as well; the keycodes seem to be
off by one. (For example the HID Report 4b 00 04 00 00 00 00 00
produces a "b" in OSX instead of an "a")
I am trying to determine two things. 1) Are the HID Descriptors
below wrong in some way? If so, I can probably get the vendor to
change them, provided they don't lose Windows compatibility. 2)
since there are units already in existence, can a Mac OS X Device
Driver be deployed to "fix" the device's HID behavior.
I have made some progress on point #2 and have created a USB driver
for the device (which inherits from IOHIDDevice in the normal way)
which can successfully "repair" the keyboard HID Reports to produce
the correct behavior. I haven't been able to figure out how to fix
the mouse HID Reports. If the mouse HID Reports can't be fixed, my
only idea is to attempt to post and synthesize those mouse actions
directly without going through handleReport() in IOHIDDevice. I
know how to do that in userland using CGPostMouseEvent(). What is
the appropriate mechanism in the kernel?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden
