[RFC wayland] protocol: Add high-resolution wl_touch timestamp event

[Alexandros Frantzis]

On Tue, Nov 21, 2017 at 10:52:00PM +0800, Jonas Ådahl wrote:
> On Tue, Nov 21, 2017 at 03:45:48PM +0200, Alexandros Frantzis wrote:
> > wl_touch events currently use a 32-bit timestamp with millisecond
> > resolution. In some cases, notably latency measurements, this resolution
> > is too coarse-grained to be useful.
> > 
> > This protocol update adds a wl_touch.timestamp event, which is emitted
> > just before an up, motion or down touch event. The timestamp event
> > contains a high-resolution, and ideally higher-accuracy, version of the
> > 'time' argument of the up/motion/down event that follows.
> > 
> > From a client implementation perspective clients can just ignore this event if
> > they don't care about the improved resolution. Clients that care just need to
> > keep track of the last timestamp event they receive and associate it with the
> > next up/motion/down event that arrives.
> > 
> > Some points for discussion:
> > 
> > 1. Should there be a request to explicitly enable/disable the timestamp event
> >    (to reduce extra event overhead when improved timestamps are not needed)?
> 
> Is there any overhead though? Or are you assuming compositors compress
> events when it wouldn't be enabled, or that it'd some how take more
> effort to fetch higher resolution timestamps?

I am more concerned with the potential overhead of sending, receiving
and handling two events instead of one for each touch event (timestamp
followed by up/down/motion). I don't know if the overhead is important
enough to be a real concern, but I know it's not zero.

The issue is somewhat mitigated at the moment since if a client doesn't
care about the new timestamp the wl_touch version number will probably
be < 7, so no event will be sent at all. However, if we add new features
in versions > 7 and a client needs them, they will also get the
timestamp events, which they may not care about.

<snip>
> > +    <!-- Version 7 additions -->
> > +
> > +    <event name="timestamp" since="7">
> > +      <description summary="high-resolution timestamp event">
> > +        The timestamp event is sent just before a wl_touch.up, wl_touch.motion
> > +        or wl_touch.down event and provides a high-resolution version of the
> > +        time argument of the event that follows.
> > +
> > +        The timestamp provided by this event is at least as accurate
> > +        as the timestamp provided by the wl_touch event that follows.
> > +      </description>
> > +      <arg name="tv_sec_hi" type="uint"
> > +           summary="high 32 bits of the seconds part of the timestamp"/>
> > +      <arg name="tv_sec_lo" type="uint"
> > +           summary="low 32 bits of the seconds part of the timestamp"/>
> > +      <arg name="tv_nsec" type="uint"
> > +           summary="nanoseconds part of the timestamp"/>
> 
> Is nano-seconds really necessary? FWIW, you'll only get timestamps with
> up to micro seconds granularity from libinput, and protocol wise it'd be
> a simple usec_hi::u32, usec_lo::u32 pair, and in code it could be passed
> around as a uint64_t (as is done in libinput).
>
> ALso, tv_nsec as a 32 bit uint doesn't seem enough. In struct timesec
> tv_nsec is 64 bit.

I chose this scheme for two reasons:

1. Primarily to be consistent with how other events carry high-resolution
   timestamp information. In particular I copied the scheme from
   wp_presentation.presented.

2. Secondarily because it ~matches timespec, which is a standard posix
   type.

In this scheme, nanoseconds being 32 bits is fine for normalized
representations of timespec, i.e, where nsec is always < 10^9 (1 sec),
and I think this was the rationale for using 32 bits for it (but I will
let Pekka answer authoritatively).

I am not overly attached to this scheme, but there is some precedence
for it in existing protocols, and I would rather we didn't introduce yet
another scheme, unless it's one that we decide that we want to try to
standardize on, or at least recommend, for future high-res
timestamps.

Thanks,
Alexandros