Skip to content
Snippets Groups Projects
Select Git revision
  • test
  • fifteen-qpr0-new
  • fifteen default
3 results
Search by author
  • Any Author
  • Farzin Kazemzadeh Farzin Kazemzadeh itisFarzin
1 author
  1. Feb 11, 2024
  3. Feb 08, 2024
    • Harry Cutts's avatar
      uinput: delay from the end of the last delay · b959f744
      Harry Cutts authored 
      If we want to inject events at predictable times, then we shouldn't take
into account the current time when scheduling those injections, as that
could change depending on the timings of the process sending commands to
uinput. Instead, assume that the process sending commands intends time
offsets between injected events to be as close as possible to those
specified in the delay commands.

Bug: 310958309
Test: atest CtsInputTestCases
Change-Id: I3ceab49bd6f492244e53d3263bf10802353853c2
      b959f744
    • Harry Cutts's avatar
      uinput: Specify timestamps when injecting events from evemu · ee829890
      Harry Cutts authored 
      Last year support for specifying timestamps for uinput events was added
to the Linux Kernel [0]. This allows us to give precise timestamps for
events being played back from an evemu recording, despite the actual
times at which we inject them being imprecise due to how threads and
the kernel are scheduled.

[0]: https://lore.kernel.org/lkml/20230427000152.1407471-1-biswarupp@google.com/

Bug: 310958309
Test: with the patch added to the device's kernel, play back pointing
      stick and touchscreen recordings. Compare `getevent -lt` output
      with the timestamps in the recordings to check that the offsets
      between timestamps match (e.g. using a spreadsheet).
Test: atest UinputTests
Change-Id: If486cdb7218918aca64e6561f9fc2f30acce736a
      ee829890
    • Harry Cutts's avatar
      uinput: use nanoseconds for delay durations · 8767c663
      Harry Cutts authored 
      evemu recordings use microseconds for their time intervals, but we can
only schedule handler calls in Device at millisecond precision. So far
we've converted the microseconds into milliseconds in EvemuParser, which
means that the precision losses compound over time (since each delay
will be slightly shorter than it should be, and the next delay will
start from that slightly earlier time, etc.). Keeping the delay
durations in a more precise unit up until the very last moment means
that we'll only get the precision loss once for each event. Since it's
somewhat uncommon to use microseconds elsewhere in Android code, and we
get the system time in nanoseconds, we may as well use nanoseconds
rather than microseconds.

Bug: 310958309
Test: play an evemu recording through uinput
Test: atest UinputTests
Change-Id: I68d54c05214ae778167adfd0d3fc9a345454c336
      8767c663
  5. Jan 30, 2024