I'm creating an embedded application that hosts a USB mouse. I'm trying to make it generic for any USB HID mouse/trackball/whatever. I've discovered that mice report differently... while they mostly all report +-127 relative X/Y coordinates the 'feel' of the application changes drastically between different models, in that some move very slowly and others move very quickly. I'm assuming that this relates to the physical size of the logical space the mouse reports.

While HID descriptors have specific fields for this, mice never use them... at least, for the boot-mode I'm using (no drivers here!) (edit: mice don't start out in boot mode, my mistake). At this point I'm reduced to creating tables keyed on VID/PID; this means that I'll have to test each mouse and create tunings for it, something I'm already tired of (and the customer's tired too!).

You can take these mice and plug them into Windows and get decently equivalent movement from them. I'm watching for special drivers and the normal driver I see is the generic 2006 HID from MS.

My main question: how is this handled in typical OS's? Am I missing something, like perhaps that mice that move more quickly have a shorter reporting interval (I haven't read the endpoint descriptor)? Or did someone have to go through and make a table of DPI for all VID/PID combinations? If they'd just put in physical vs. logical into the report descriptor then this would work like it should! Please help...

  • \$\begingroup\$ Have you implemented mouse "acceleration"? \$\endgroup\$ – pjc50 Dec 6 '12 at 17:38
  • 2
    \$\begingroup\$ Mice have their inherent resolution(s), but the host OS can also poll at different rates. For this reason, operating systems usually let you fine tune mouse speed and mouse acceleration. I'm pretty sure there's no standard on what a mouse have to report in terms of unit conversion... and I'd be willing to bet you're stuck doing these custom table mappings if you want to normalize mouse response. \$\endgroup\$ – Toby Lawrence Dec 6 '12 at 17:40
  • 1
    \$\begingroup\$ @TobyLawrence - Mouse resolution and poll-rates are not the same! If you poll a mouse more often, it will report smaller delta-position values per-poll. However, the underlying DPI will not change. To simulate a lower DPI, you would have to divide the delta-position values by the ratio of hardware-DPI to desired DPI. \$\endgroup\$ – Connor Wolf Mar 22 '13 at 21:16
  • 1
    \$\begingroup\$ @TobyLawrence - The rate of polling shouldn't influence the mouse movement at all. It just affects the responsiveness. That is the point I was trying to get at. \$\endgroup\$ – Connor Wolf Mar 24 '13 at 3:22
  • 1
    \$\begingroup\$ Essentially, the mouse integrates the \$\Delta X\$ and \$\Delta Y\$, and returns the values every time the computer request them. If you poll more often, the reported deltas are smaller, but if you sum them over time (as you do to draw the cursor), the overall result is the same. \$\endgroup\$ – Connor Wolf Mar 24 '13 at 3:24

Try the word MICKEY http://www.webopedia.com/TERM/M/mickey.html

Note, some OS (I believe Windows and Mac does this too) automatically change different "dot-per-inch" depending on the speed of human-user movement. if user move mouse fast, it increase "dot-per-inch". When user move mouse slowly, like doing fine painting on photoshop, it decrease so that user can control/move one or a few pixels.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.