On Tue, Dec 05, 2017 at 06:07:02PM +0200, Alexandros Frantzis wrote:
> wl_pointer, wl_keyboard and wl_touch events currently use a 32-bit
> timestamp with millisecond resolution. In some cases, notably latency
> measurements, this resolution is too coarse to be useful.
>
> This protocol provides additional high-resolution timestamps events,
> which are emitted before the corresponding input event. Each timestamp
> event contains a high-resolution, and ideally higher-accuracy, version
> of the 'time' argument of the first subsequent supported input event.
>
> Clients that care about high-resolution timestamps just need to keep
> track of the last timestamp event they receive and associate it with the
> next supported input event that arrives.
>
Hi all,
a few additional discussion notes (some copied from the RFC discussion):
1. Supported pointer/keyboard/touch events
At the moment the protocol is phrased to be forward-compatible with
new pointer/keyboard/touch events. For example, for touch:
"represents a subscription to high-resolution timestamp events for
for all wl_touch events that carry a timestamp."
This guards against making input-timestamps protocol updates for new
input events (unless we add a new input category), and is easy to
implement in practice.
2. Timestamp accuracy guarantee
Currently: "The timestamp provided by this event ... is at least as
accurate as the associated input event timestamp."
In a previous discussion it was suggested that an option would be for
the server to advertise support for this protocol only if it can
provide better (than millisecond) accuracy. My concern with such an
approach is that there may be cases where only some input objects can
provide high-accuracy timestamps, so the guarantee may not be
globally applicable.
3. Clocks domains
The high-resolution timestamps are guaranteed to be in the same clock
domain as the input event timestamps (for which the clock domain is
currently unspecified).
4. Support for input events from unstable protocols (e.g. tablet)
I opted not to include support for input events from unstable
protocols. The rationale is that this protocol was created in order
to fix the deficiencies (for certain use cases) of protocols that we
are unable to change due to compatibility restrictions. Unstable
protocols are not subject to such restrictions and can therefore be
updated to use high-resolution timestamps instead of relying on an
external protocol to provide such functionality.
5. Frame event timestamps
It was suggested that this protocol could provide timestamps for
frame events which currently don't carry one in the core protocol. In
this proposal I have chosen to maintain consistency with the way
timestamps are emitted in the core protocol, i.e., emit timestamp
events only for input events that already carry a timestamp. Adding a
frame timestamp when one is not already present would also further
complicate client implementations that need to support falling back
to the normal timestamps when this protocol is not present.
A proof of concept implementation for weston can be found at:
https://gitlab.collabora.com/alf/weston/commits/zwp-input-timestamps
Thanks,
Alexandros
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
