[RFC wayland] protocol: Add high-resolution wl_touch timestamp event
ppaalanen at gmail.com
Fri Nov 24 11:28:09 UTC 2017
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.
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.
> > > + <!-- 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
> 2. Secondarily because it ~matches timespec, which is a standard posix
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel