Date: Thu, 20 Oct 2005 10:37:05 -0500 (CDT) From: Sergey Babkin <babkin@verizon.net> To: Kris Maglione <bsdaemon@comcast.net>, freebsd-hackers@freebsd.org Subject: Re: USB mouse problem Message-ID: <17797651.1129822626662.JavaMail.root@vms068.mailsrvcs.net>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17797651.1129822626662.JavaMail.root>