| Summary: | bad frequency calculation in mouse-dpi-tool | ||
|---|---|---|---|
| Product: | libevdev | Reporter: | CircleCode <codronm+circlecode> |
| Component: | Core | Assignee: | Peter Hutterer <peter.hutterer> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | codronm+circlecode, peter.hutterer |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
evemu-record output for 100mm movement along the x axis
mouse-dpi-tool output for 100mm movement along the x axis evemu-record output for 3 successive movements |
||
|
Description
CircleCode
2016-09-15 07:48:15 UTC
Created attachment 126532 [details]
mouse-dpi-tool output for 100mm movement along the x axis
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. Created attachment 126567 [details]
evemu-record output for 3 successive movements
seems like it occurs every time the move starts a move
(typo) seems like it occurs every time the mouse starts a move 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. 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.