11

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...

user16719
  • 111
  • 3
  • Have you implemented mouse "acceleration"? – pjc50 Dec 06 '12 at 17:38
  • 2
    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. – Toby Lawrence Dec 06 '12 at 17:40
  • Toby, thanks for your comments... my point is that the OS is already doing something like this, I just can't figure out what they're doing. And pjc50... mouse acceleration doesn't enter into this, the acceleration happens afterward (and yes, I have an acceleration scheme). I'm going to try putting the mice into 'boot mode'... I was mistaken above, the mice start out in normal mode and the boot software sends them a config command to put them into boot mode. This will be my last best hope... failing that, it's the giant table of mice for me. – user16719 Dec 10 '12 at 16:42
  • generic driver information in the BIOS may be reviewed along with HID SDK for suitable use in embedded code, but BIOS is usually proprietary. – Tony Stewart EE75 Dec 16 '12 at 20:57
  • Richman, thanks for your comment... I have no problem with BIOS usage, the format for BIOS is a universal 3-byte format, you send a setConfig(0) to put into BIOS boot mode... but my USB stack is broke for that mode, so more work necessary. I'm asking here how the OS does it... without physical size descriptors. At the moment I'm pursuing the boot mode, I'll ask the AVRFreaks about the stack. Again, thanks for your comments. – user16719 Dec 17 '12 at 00:57
  • 1
    @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. – Connor Wolf Mar 22 '13 at 21:16
  • @ConnorWolf Ehm, I never said they were the same. Go back and re-read what I said. :P – Toby Lawrence Mar 22 '13 at 23:42
  • @TobyLawrence - `Mice have their inherent resolution(s), but the host OS can also poll at different rates.` I guess this could be interpreted in two different ways. – Connor Wolf Mar 22 '13 at 23:50
  • @ConnorWolf I mean, I think it's pretty clear cut - mice have a fixed DPI (or a set of fixed DPIs to choose from) that then influence the mouse's rate of movement based on how often you poll. As you said, the underlying DPI doesn't change... which is echoed by "inherent resolution." There's no disagreement here, you're just reading into things more than you need to. :P – Toby Lawrence Mar 23 '13 at 13:14
  • 1
    @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. – Connor Wolf Mar 24 '13 at 03:22
  • 1
    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. – Connor Wolf Mar 24 '13 at 03:24

1 Answers1

1

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.

EEd
  • 989
  • 4
  • 12