Bug 97812 - bad frequency calculation in mouse-dpi-tool
Summary: bad frequency calculation in mouse-dpi-tool
Status: RESOLVED FIXED
Alias: None
Product: libevdev
Classification: Unclassified
Component: Core (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Peter Hutterer
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-15 07:48 UTC by CircleCode
Modified: 2016-10-26 04:20 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
evemu-record output for 100mm movement along the x axis (9.36 KB, text/plain)
2016-09-15 07:48 UTC, CircleCode
Details
mouse-dpi-tool output for 100mm movement along the x axis (1001 bytes, text/plain)
2016-09-15 07:48 UTC, CircleCode
Details
evemu-record output for 3 successive movements (9.66 KB, text/plain)
2016-09-16 07:20 UTC, CircleCode
Details

Description CircleCode 2016-09-15 07:48:15 UTC
Created attachment 126531 [details]
evemu-record output for 100mm movement along the x axis

According to evemu-record, my mouse sends 10 units movements every 70ms
for the same move, mouse-dpi-tool gives a frequency around 20000

- the mouse is a ThinkPad X1 Wireless Touch Mouse
  (http://shop.lenovo.com/us/en/itemdetails/4X30K40903/460/0E80436C80A748E6AA76791FC42C9CA3),
  connected through bluetooth
- the computer is a lenovo X1 Carbon 4th generation
- the distribution is arch linux
Comment 1 CircleCode 2016-09-15 07:48:49 UTC
Created attachment 126532 [details]
mouse-dpi-tool output for 100mm movement along the x axis
Comment 2 Peter Hutterer 2016-09-15 21:38:24 UTC
Cause here are the first two events that are within 723µs of each other. The mouse-dpi-tool chooses the max frequency between events, so that if a user stops moving or moves too slow it doesn't give us the wrong (too-low) frequency later.

Because you get those two events immediately after each other the frequency value is wrong. All other events are 70ms apart, so clearly that's the real frequency of the device.

To fix this, I'd need to know more on when exactly this happens. It could even be an evemu bug (or even kernel).

Leave evemu running and stop moving the mouse, wait a few sec, then move again. Do you get the 0ms-spaced events at the beginning of each movement? Or is it just the first events of an evemu recording?

If the latter, can you reproduce this with evtest? 
https://cgit.freedesktop.org/evtest/

If it always (or almost always) happens on the first events, it's probably some power wakeup-related issue. We can paper over that.
Comment 3 CircleCode 2016-09-16 07:20:37 UTC
Created attachment 126567 [details]
evemu-record output for 3 successive movements

seems like it occurs every time the move starts a move
Comment 4 CircleCode 2016-09-16 07:21:48 UTC
(typo) seems like it occurs every time the mouse starts a move
Comment 5 Peter Hutterer 2016-09-19 00:35:45 UTC
after looking at this for a bit, I'm wondering if we should really attempt to fix this in software. Looking at the output, it's clear that the rate is 1/70ms. But what the device appears to do is go to sleep quickly, then buffer a few events on the new move and send them all at once on BT wakeup.

I suspect anything we put in the dpi tool here will just obscure any other issues, so it may be best to just print out a warning and let the user find out the details.
Comment 7 Peter Hutterer 2016-10-26 04:20:31 UTC
commit 61f0a0f9ade8712d81befe10617f56b71038d730
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Sep 19 10:51:52 2016 +1000

    tools: print the mean frequency together with the max frequency


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.