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

[Pekka Paalanen]

On Tue, 21 Nov 2017 18:20:08 +0200
Alexandros Frantzis <alexandros.frantzis at collabora.com> wrote:

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

Hi,

I would say that the overhead in insignificant. The overhead is 8 bytes of
data, and a dispatch.

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

Correct.

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

Right. We're talking about input events, "surely millisecond precision
is enough" - and it wasn't. Surely microsecond precision is enough?
Well, for all we can imagine today, but...

I see no harm in going full timespec.


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/20171124/e3ae1b25/attachment.sig>