[PATCH wayland-protocols] unstable: Add input-timestamps protocol

[Pekka Paalanen]

On Tue, 5 Dec 2017 18:20:35 +0200
Alexandros Frantzis <alexandros.frantzis at collabora.com> wrote:

> 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.

Hi Alf,

I think that would still fall under "can", which is different from
"guaranteed" better accuracy timestamp. But there is no need to discuss
this in the protocol spec at all. Each compositor can make its decision
whether to expose this extension or not.

Clients should not make any assumptions about the accuracy based on the
presence of the extension. That's the important bit.

> 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.

A very good point.

> 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.

I don't think the two are conflicting goals.

We could have the high precision timestamp event emitted at least (and
preferably only) once per each event sequence ending in a frame event
that contains at least one event that carries a low precision timestamp.

The diagonal scrolling was used as the (rare) example where an actual
reduction in the number of events could be seen. Currently the core
protocol provides a low precision timestamp redundantly multiple times
(two exis events) when one would be enough. By definition the
timestamps on the axis events are the same.

> A proof of concept implementation for weston can be found at:
> 
>     https://gitlab.collabora.com/alf/weston/commits/zwp-input-timestamps


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171211/c90633a8/attachment.sig>