large proportion of invalid input event timestamps on soraka |
||
Issue descriptionWe're seeing some pretty weird input metrics coming back from soraka devices. In the logs, 40% of input timestamps seem to be bogus on the basis that they are days in the past. See https://groups.google.com/a/chromium.org/d/msg/input-dev/1ez9ojul490/ZlCahhigAQAJ and in particular the dataset at https://colab.corp.google.com/drive/1Hf5el7nl_ElIP9EksZDhWOmzKsfc1ta_ Sean, I think the only way we can get timestamps other than by reading the clock directly is from your gestures patch at https://chromium-review.googlesource.com/938851 Is it possible MSC_TIMESTAMP is not working as you expect?
,
Jul 25
Strange that it would happen on eve as well as soraka, since there are no MSC_TIMESTAMP events on eve's touchpad. I'll take a closer look tomorrow.
,
Jul 26
My eve touchpad is reporting MSC_TIMESTAMP.
,
Jul 26
You're right, I needed to update my eve. I haven't been able to reproduce a problem with MSC_TIMESTAMP on my device. I also tested a couple of possible scenarios with modifications to the unittests and found no problem: - MSC_TIMESTAMP rollover (happens after 30 minutes of continuous touchpad contact), and then reset to 0. - MSC_TIMESTAMP reset to slightly above 0 (if that event was dropped) - combination of the above Is it possible to see metrics for the event type and/or source on those bad timestamps?
,
Jul 26
We could record event type or source, though it would require a privacy review and a bit of eng work. Nothing crazy, but it isn't completely trivial.
,
Aug 3
This bug has an owner, thus, it's been triaged. Changing status to "assigned". |
||
►
Sign in to add a comment |
||
Comment 1 by spang@chromium.org
, Jul 25Components: Internals>Input>Touch>Pad