For long-running recordings it's useful to know what the actual time was when
a particular event occured. A user can simply check the clock or system logs
for the time and thus know which portion of the recording to focus on.
Let's print the time into the recording, every 5 seconds (aligned at the 5,
10, 15s marks) or, if no events occured in the last 5 seconds, before the next
event. This granularity should be enough to identify the interesting parts of
a recording.
Let's print this as a comment until we have a use-case that requires parsing
this data.
The timer is the simplest approach, it just repeats at a fixed 5 seconds
interval from startup. There may be time drift, we can fix that if needed.
Fixes#560
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, this makes the code slightly more readable, especially
once we start adding more "special" fds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, this makes the code slightly more readable, especially
once we start adding more "special" fds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Minor tidying up the code, set the default values for all fds in the same loop
instead of having it split to wherever the fd is created.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Too many recordings end up with the device list at the top when users redirect
stderr and stdout to the recordings file. This breaks yaml parsing and
requires manual removal of the first few lines.
Avoid this by prefixing the lines with a command character, this way the yaml
stays correct.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Leaving in-place all those where we know the length of the prefix, but
replacing all those where we were calling strlen on the prefix.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libinput record touchpad.yml /dev/input/eventX
or just
libinput record touchpad.yml
are simpler invocations and since we're quite limited in what we can record
(i.e. only device files) we can just check the argument list to figure out
whether there is something to record to.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Processing os-release in the same buffer that the dmi modalias used caused the
dmi to be recorded as 'dmi: "VERSION_ID=31"'. The cause for that was simply
that the dmi modalias was read but not printed until after the os-release
information was processed.
Fix this two-fold: rearrange that each part now reads and prints in
one go, and rename the buffers so we don't re-use them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because sometimes it's useful to know what distro a recording was made on, and
the kernel version doesn't always reveal that.
Fixes#428
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
event->time ended up being an uninitialized field. Introduced in 5dc1a7e, the
event here isn't a struct input event but rather our internal event struct.
Fix this and reshuffle the time handling a bit so it's a bit more obvious
here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we want to record multiple events, let's just specify multiple event nodes.
No need for a specific extra argument here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Positive side-effect - this exposed a bunch of missing #includes that got
pulled in by other headers before.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The first event we receive is set to a 0ms offset anyway. Setting last_ms to 0
on the first event means the first two events have +0ms offset printed to the
log. Skip it, so the second event has the right offset.
This is human-readable data only, no effect on the recording file itself.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that all device quirks are in the quirks subsystem we have to print those
instead of just the udev devices.
Since libinput-record is there to record system devices, the system-installed
quirk list is used (without any commandline overrides right now). This is
useful to capture misconfigurations or missing quirks on the host system.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/58
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Leftover from a previous version where printing and handling an event was
identical. Now we may handle events but not actually print them until a bit
later, so other events may have a (wrong) zero timestamp.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Common problem: some touch sequence does something to confuse libinput but it
cannot easily be captureed. The result is a long sequence of touche that need
to be picked apart and isolated.
Print an easy-to-search for message in the evdev output that signals that the
device touch state is now neutral (i.e. no finger down). Same can be achieved
by searching for BTN_TOOL_FINGER but that provides false positives for
switching between one and two fingers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Collect libinput events together with the evdev events and print them to the
log. This makes it possible to debug the full behavior of a user's machine
rather than having to replay it with potential different race conditions/side
effects.
Example event output:
- evdev:
- [ 2, 314443, 4, 4, 57] # EV_MSC / MSC_SCAN 57
- [ 2, 314443, 1, 57, 1] # EV_KEY / KEY_SPACE 1
- [ 2, 314443, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +87ms
libinput:
- {time: 2.314443, type: KEYBOARD_KEY, key: 57, state: pressed}
- evdev:
- [ 2, 377203, 4, 4, 57] # EV_MSC / MSC_SCAN 57
- [ 2, 377203, 1, 57, 0] # EV_KEY / KEY_SPACE 0
- [ 2, 377203, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +63ms
libinput:
- {time: 2.377203, type: KEYBOARD_KEY, key: 57, state: released}
Note that the only way to know that events are within the same frame is to
check the timestamp. libinput keeps those intact which means we can tell that
if we just had an evdev frame with timestamp T and get a pointer motion with
timestamp T, that frame caused the motion event.
So far, only key, pointer and touch events are printed. We also
hardcode-enable tapping where available until we have options to enable this
on the commandline just because that's useful to have.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
