vasilito
f31522130f
Build system (5 gaps hardened): - COOKBOOK_OFFLINE defaults to true (fork-mode) - normalize_patch handles diff -ruN format - New 'repo validate-patches' command (25/25 relibc patches) - 14 patched Qt/Wayland/display recipes added to protected list - relibc archive regenerated with current patch chain Boot fixes (fixable): - Full ISO EFI partition: 16 MiB → 1 MiB (matches mini, BIOS hardcoded 2 MiB offset) - D-Bus system bus: absolute /usr/bin/dbus-daemon path (was skipped) - redbear-sessiond: absolute /usr/bin/redbear-sessiond path (was skipped) - daemon framework: silenced spurious INIT_NOTIFY warnings for oneshot_async services (P0-daemon-silence-init-notify.patch) - udev-shim: demoted INIT_NOTIFY warning to INFO (expected for oneshot_async) - relibc: comprehensive named semaphores (sem_open/close/unlink) replacing upstream todo!() stubs - greeterd: Wayland socket timeout 15s → 30s (compositor DRM wait) - greeter-ui: built and linked (header guard unification, sem_compat stubs removed) - mc: un-ignored in both configs, fixed glib/libiconv/pcre2 transitive deps - greeter config: removed stale keymapd dependency from display/greeter services - prefix toolchain: relibc headers synced, _RELIBC_STDLIB_H guard unified Unfixable (diagnosed, upstream): - i2c-hidd: abort on no-I2C-hardware (QEMU) — process::exit → relibc abort - kded6/greeter-ui: page fault 0x8 — Qt library null deref - Thread panics fd != -1 — Rust std library on Redox - DHCP timeout / eth0 MAC — QEMU user-mode networking - hwrngd/thermald — no hardware RNG/thermal in VM - live preload allocation — BIOS memory fragmentation, continues on demand
47 lines
1.7 KiB
ReStructuredText
47 lines
1.7 KiB
ReStructuredText
|
|
.. _timestamps:
|
|
|
|
==============================================================================
|
|
Timestamps
|
|
==============================================================================
|
|
|
|
.. _event_timestamps:
|
|
|
|
------------------------------------------------------------------------------
|
|
Event timestamps
|
|
------------------------------------------------------------------------------
|
|
|
|
Most libinput events provide a timestamp in millisecond and/or microsecond
|
|
resolution. These timestamp usually increase monotonically, but libinput
|
|
does not guarantee that this always the case. In other words, it is possible
|
|
to receive an event with a timestamp earlier than the previous event.
|
|
|
|
For example, if a touchpad has :ref:`tapping` enabled, a button event may have a
|
|
lower timestamp than an event from a different device. Tapping requires the
|
|
use of timeouts to detect multi-finger taps and/or :ref:`tapndrag`.
|
|
|
|
Consider the following event sequences from a touchpad and a mouse:
|
|
|
|
|
|
::
|
|
|
|
Time Touchpad Mouse
|
|
---------------------------------
|
|
t1 finger down
|
|
t2 finger up
|
|
t3 movement
|
|
t4 tap timeout
|
|
|
|
|
|
For this event sequence, the first event to be sent to a caller is in
|
|
response to the mouse movement: an event of type
|
|
**LIBINPUT_EVENT_POINTER_MOTION** with the timestamp t3.
|
|
Once the timeout expires at t4, libinput generates an event of
|
|
**LIBINPUT_EVENT_POINTER_BUTTON** (press) with a timestamp t1 and an event
|
|
**LIBINPUT_EVENT_POINTER_BUTTON** (release) with a timestamp t2.
|
|
|
|
Thus, the caller gets events with timestamps in the order t3, t1, t2,
|
|
despite t3 > t2 > t1.
|
|
|
|
libinput timestamps use **CLOCK_MONOTONIC**.
|