diff options
| author | Peter Hutterer <peter.hutterer@who-t.net> | 2015-08-07 10:36:55 +1000 |
|---|---|---|
| committer | Peter Hutterer <peter.hutterer@who-t.net> | 2015-08-18 11:57:07 +1000 |
| commit | eba96a4d2be7260b5843e65c4b99c8b06a1f4c9d (patch) | |
| tree | 7cd912e3ee21efecff76fd9b4104b43cb7c1e99e | |
| parent | 3d8401fa85580477e94b7454bd72e521cd53ecf5 (diff) | |
Record events with an initial offset of 1µs
Since 63df84261355d, the first event frame always has a timestamp of 0.0. When
reading those events we'll replay the first event frame, and set evtime. On
the second frame, evtime is 0.0 which evemu_read_event_realtime() takes as
"uninitialized" and thus resets it again, causing the second frame to be
replayed immediately instead of waiting for the correct time.
Since this behavior is part of the API, work around this by giving the first
event an offset of 1µs. Since the 0 offset was to make reading event logs
easier, this offset won't hurt us. It won't change existing recordings, but
over time this will be less of an issue and it's less of a hack than trying to
work magic values into evemu_play/evemu_read_event_realtime.
The alternative to this hack would be to add another API (or break the current
one), but it's not yet worth it for the little gain we get from it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
| -rw-r--r-- | src/evemu.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/evemu.c b/src/evemu.c index 7ca4c78..ee24631 100644 --- a/src/evemu.c +++ b/src/evemu.c @@ -768,7 +768,7 @@ int evemu_record(FILE *fp, int fd, int ms) long time; if (offset == 0) - offset = time_to_long(&ev.time); + offset = time_to_long(&ev.time) - 1; time = time_to_long(&ev.time); ev.time = long_to_time(time - offset); |