USB mouse problem

[Sergey Babkin]

>I do have the mouse working, but with a couple of issues. The main problem 
>seems to be that the last 3 bytes of the sc_data seem to be wrong. Their 
>values never change from the time that the device is attached. They're usually 
>all 0, but sometimes have values. The forth byte is supposed to hold the Z 
>axis, but I never get any Z axis data, at all (except for the possible random 
>value in the forth byte previously mentioned).  When I move the scroll wheel, 
>I get a lot of events, but the data is all zeros, except, possibly, for the 
>last 3 bytes, which have the same values as before.

First, a disclaimer: I haven't looked at the FreeBSD
USB mouse driver and can't tell if what I say is
truly relevant.

But, it looks to me like it does not use the HID
descriptor. The other possibility is that the HID
descriptor in your device is wrong (as in "a firmware
bug").

What the HID descriptor is: The USB spec is very 
clever, and requires that the normal USB devices 
provide not only the data itself by also the 
descriptor tables describing the meaning of the 
data - which fields are where and how they are 
formatted. Or at least it requires that for the
Human Interface Devices (HID).

The descriptors are stored in ROM inside
the device and are sent to the computer on request.
The exact formatting of the descriptors is complicated
but in essence it boils down to the triplets
of (meaning, location, format). There are pre-defined
standardized tables of possible meanings (functions) and the
codes associated with them. For the mouse the 
functions would be such as "X axis movement", 
"Y axis movement", "Button 1", "Button 2", "Button 3"
etc. These tables are hierarchical: i.e. some meanings
are applicable to any HID devices, some for any
kind of pointer device, some specifically for mice.

Of course the manufacturer includes only those
meanings in the descriptor that are actually
supported by the device. Then again the manufacturer 
is free to include any extra device-specific
information that is not described by the descriptor.
To use this device-specific information a device-
specific driver would have to be used. On the
other hand, a generic driver can be used with
any device that provides a suitable descriptor
with needed functions.

So how a generic mouse drived should work: when writing the
driver its author looks up the codes for all the
related functions in the manual. Then when a mouse
is connected, the driver should query its descriptor,
and then go through it and find the information about
these functions and remember it. Then when it receives
the data from the device, it should look for data
in it according to what it has found in the descriptor.
And similarly for constructing messages to be sent
to the device.

>From your description it looks like the present driver
does not go into all this trouble but instead assumes
a particular hardcoded format of incoming data.
But again, I might be wrong.

-SB