Bug 87435

Added in http://cgit.freedesktop.org/systemd/systemd/commit/?id=90d37f7e8f.

I have the same mouse, same PN. But I varying results. If I move the mouse slowly my results are more constant with 600dpi at 125Hz. If I move the mouse more quickly I sometimes get the 142.9Hz, and higher DPIs. Could the mouse have a variable frequency, and could that mess with the results?

(In reply to sam tygier from comment #2)
The sensor could also be failing. If it's inconsistent, there's not much we can do about it anyway.

I have a mouse that behaves like this as well. The microsoft wireless laser 5000. The spec specifically states that the frequency is dynamic:
"Imaging Rate: Dynamically adaptable to 8000 frames per second"

I have seen it go at:
200.0Hz - (1/200.0 = 0.005)
166.7Hz - (1/166.7 = 0.006)
142.9Hz - (1/142.9 = 0.007)
125.0Hz - (1/125.0 = 0.008)

mouse-dpi-tool will always show the highest so you need to try a few times to see them all.

About the DPI you need to be select a suitable surface to test on with an optical mouse. I tried a few different surfaces when I tried to get my mouse to achieve the DPI listed in the spec for my optical mice. Also check for hairs or dust in the sensor. Had that problem too.

the dpi tool can only divide the events seen by the time passed. problem is that we don't know if a pause of X ms is caused by the mouse not moving or the frequency being low, so we pick the highest frequency we can find between events.

for most cases this shouldn't be a problem, anyone who wants to use the actual frequency needs to look at the event timestamps anyway so the maximum value is fine. and for those devices with fixed settings we can have multiple frequency entries.

so I think we're good here but I'll add some comments to the hwdb and the dpi tool to note the frequency is the maximum frequency. I don't think it's necessary to add another tag to mark it as dynamic. any comments?

That sounds reasonable. I was working on a patch for mouse-dpi-tool to show the frequencies in a histogram. If we only really need the max frequency then current code is fine. In my testing the mouse would use 142.9Hz ~90% of the time. I could not find any specific steps to trigger the higher or lower frequencies. I guess the user just has to move the mouse for a while and hope we have found the max?

When measuring I used a blank piece of paper with some lines to indicate the distance I want to move. For laser mice I usually get a slightly higher dpi than the mouse was specified for. E.g. 855 from a mouse claiming to do 800. For the optical mice I got a lot worse dpi. ~200 dpi less than the spec for my case. Simply drawing a lot of doodles with a pen on the paper helps.

For all the mice I tested I was able to find an advertised dpi on the internet. I just tested that I could get reasonably close to that dpi with your tool and then used the advertised value. Does that make sense?

Nitpick: the tool truncates the frequency when creating the hwdb entry. So for 142.9Hz it will use xxx@142.

(In reply to Thomas H.P. Andersen from comment #6)
> That sounds reasonable. I was working on a patch for mouse-dpi-tool to show
> the frequencies in a histogram. If we only really need the max frequency
> then current code is fine. In my testing the mouse would use 142.9Hz ~90% of
> the time. I could not find any specific steps to trigger the higher or lower
> frequencies. I guess the user just has to move the mouse for a while and
> hope we have found the max?

pretty much. I don't know what the devices employ for frequency scaling - is it lots of little movements, lots of large movements? I honestly don't know. You can still do the frequency patch if you want though, it may be useful.

> For all the mice I tested I was able to find an advertised dpi on the
> internet. I just tested that I could get reasonably close to that dpi with
> your tool and then used the advertised value. Does that make sense?

definitely. with high enough dpis a slight erratic movement or measurement error can quickly result in odd numbers, so if the manufacturer says 1000dpi and you measure in the 900-1100 range then I'd say go with the advertised one. There's other factors involved too, if the surface isn't perfect you may not get the exact reading even if you move the right distance, etc.


> Nitpick: the tool truncates the frequency when creating the hwdb entry. So
> for 142.9Hz it will use xxx@142.

I didn't think we needed floating point frequencies tbh and I'm still not convinced that we do. Rounding otoh would be useful I guess.

(In reply to Peter Hutterer from comment #5)
> for most cases this shouldn't be a problem, anyone who wants to use the
> actual frequency needs to look at the event timestamps anyway so the maximum
> value is fine. and for those devices with fixed settings we can have
> multiple frequency entries.
> 
> so I think we're good here but I'll add some comments to the hwdb and the
> dpi tool to note the frequency is the maximum frequency. I don't think it's
> necessary to add another tag to mark it as dynamic. any comments?

I agree, we're only interested in the MAX frequency. There can be many reasons why the device reports less events. A driver should always use the timestamps to calculate movement deltas.

I adjusted the frequency to 142 in http://cgit.freedesktop.org/systemd/systemd/commit/?id=dba7635999.

and a small comment to the hwdb file: http://cgit.freedesktop.org/systemd/systemd/commit/?id=3a8d368a6184ca8b7422330b53513983088671f2