Possibly -next regression from "Input: allow drivers specify timestamp for input events"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Atif,
  I was testing today's -next with AOSP on the HiKey board and was
seeing some odd mouse behavior and I've bisected the issue down to
commit 3b51c44bd693 ("Input: allow drivers specify timestamp for input
events").

In the logcat log I'd see a number of:
 I InputDispatcher: Dropped event because it is stale.

Usually it would seem like flings weren't really responding right, and
then the UI would basically freeze for awhile (even though the mouse
cursor could still move around, the UI was just ignoring new input).

Just skimming the patch, It seems like maybe we're hitting:

if (!ktime_compare(dev->timestamp[INPUT_CLK_MONO], invalid_timestamp))

check and the device timestamp (at least occasionally) isn't
zero/"invalid" but also isn't actually correct.

If I comment out that check, and always call input_set_timestamp(dev,
ktime_get()), the issue seems to go away.

Do you have any suggestions for me to try?

thanks
-john



[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux