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

[Alexandros Frantzis]

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