[PATCH wayland-protocols] unstable: Add input-timestamps protocol
Pekka Paalanen
ppaalanen at gmail.com
Mon Dec 18 10:50:30 UTC 2017
On Wed, 13 Dec 2017 16:48:28 +0200
Alexandros Frantzis <alexandros.frantzis at collabora.com> wrote:
> On Mon, Dec 11, 2017 at 03:25:28PM +0200, Pekka Paalanen wrote:
> > On Tue, 5 Dec 2017 18:07:02 +0200
> > Alexandros Frantzis <alexandros.frantzis at collabora.com> 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.
> > >
> > > Signed-off-by: Alexandros Frantzis <alexandros.frantzis at collabora.com>
> > > ---
> > > Makefile.am | 1 +
> > > unstable/input-timestamps/README | 4 +
> > > .../input-timestamps-unstable-v1.xml | 138 +++++++++++++++++++++
> > > 3 files changed, 143 insertions(+)
> > > create mode 100644 unstable/input-timestamps/README
> > > create mode 100644 unstable/input-timestamps/input-timestamps-unstable-v1.xml
> >
> > Hi Alf,
> >
> > nice work, a comment below.
>
> Hi Pekka,
>
> thanks for the review, some comments below.
>
> > >
> > > diff --git a/Makefile.am b/Makefile.am
> > > index cabc279..4b9a901 100644
> > > --- a/Makefile.am
> > > +++ b/Makefile.am
> > > @@ -16,6 +16,7 @@ unstable_protocols = \
> > > unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml \
> > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
> > > unstable/xdg-output/xdg-output-unstable-v1.xml \
> > > + unstable/input-timestamps/input-timestamps-unstable-v1.xml \
> > > $(NULL)
> > >
> > > stable_protocols = \
> > > diff --git a/unstable/input-timestamps/README b/unstable/input-timestamps/README
> > > new file mode 100644
> > > index 0000000..3e82890
> > > --- /dev/null
> > > +++ b/unstable/input-timestamps/README
> > > @@ -0,0 +1,4 @@
> > > +High-resolution timestamps for input events.
> > > +
> > > +Maintainers:
> > > +Alexandros Frantzis <alexandros.frantzis at collabora.com>
> > > diff --git a/unstable/input-timestamps/input-timestamps-unstable-v1.xml b/unstable/input-timestamps/input-timestamps-unstable-v1.xml
> > > new file mode 100644
> > > index 0000000..5a9d120
> > > --- /dev/null
> > > +++ b/unstable/input-timestamps/input-timestamps-unstable-v1.xml
> > > @@ -0,0 +1,138 @@
> > > +<?xml version="1.0" encoding="UTF-8"?>
> > > +<protocol name="input_timestamps_unstable_v1">
> > > +
Hi Alf
> > > + <interface name="zwp_input_timestamps_v1" version="1">
> > > + <description summary="context object for input timestamps">
> > > + Provides high-resolution timestamp events for a set of subscribed input
> > > + events. The set of subscribed input events is determined by the
> > > + zwp_input_timestamps_manager_v1 request used to create this object.
> > > + </description>
> > > +
> > > + <request name="destroy" type="destructor">
> > > + <description summary="destroy the input timestamps object">
> > > + Informs the server that the client will no longer be using this
> > > + protocol object. After the server processes the request, no more
> > > + timestamp events will be emitted.
> >
> > This could be said simply:
> > "Cancel the subscription to the high-resolution timestamps."
> >
> > It's fine either way.
> >
> > > + </description>
> > > + </request>
> > > +
> > > + <event name="timestamp">
> > > + <description summary="high-resolution timestamp event">
> > > + The timestamp event is associated with the first subsequent input event
> >
> > + carrying a timestamp
> >
> > > + which belongs to the set of input events this object is subscribed to.
> >
> > This is a bit hard to write down precisely. How about:
> >
> > "The timestamp event is associated with the first subsequent input event
> > group (as defined in the respective input interface, e.g.
> > wl_pointer.frame) or single input event that already carries a
> > timestamp with less precision than this timestamp event."
> >
> > I inferred from Peter's wording that we want to require a new event for
> > a new input event/group even if the timestamp would be the same.
> > Therefore "the first" and "single".
>
> In this version I opted not to provide timestamps for frame/group events
> (see discussion notes email).
That is not what I proposed or attempted to write down. A frame event
alone would not get a timestamp event. The group would need include at
least one event with the coarse timestamp for a precise timestamp to be
sent.
> One reason is that it's not clear what a
> timestamp on a frame event (that doesn't already have a timestamp)
> refers to, and I don't think this protocol can or should try to provide
> that meaning. That's why I decided to emit high-res timestamps only for
> events that already have one.
This is exactly my intention as well.
The modification I was looking for was, when a single group contains
multiple input events with the coarse timestamp, it would be allowed to
emit only one precise timestamp event for such group. Otherwise we
would require compositors to send the same timestamp multiple times by
definition.
> Also, in terms of phrasing, my idea was that zwp_input_timestamps_v1
> wouldn't describe the set of input events it emits timestamps for, so it
> wouldn't impose assumptions that may not be true generally. The
> subscribed input event sets are described in the respective
> zw_input_timestamps_manager_v1.get_*_timestamps requests. In the spirit
> of this, if we wanted to support the frame event we would add it in the
> respective get_*_timestamp description.
I suppose. Grouping is a general concept, so I thought it would be
possible to describe it in general without details of each input
interface. The example of wl_pointer is there to clarify what the vague
wording was trying to say.
> > > +
> > > + The timestamp provided by this event is a high-resolution version of
> > > + the timestamp argument of the associated input event. The provided
> >
> > "..of the associated input event(s)." would perhaps cover the above
> > change in wording?
> >
> > > + timestamp is in the same clock domain and is at least as accurate as
> > > + the associated input event timestamp.
> > > + </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"/>
> > > + </event>
>
> I wanted to add here that one thing you brought up in the weston event
> tests patchset is the need to more accurately define the representation
> of the high-res timestamps in terms of normalization. I will do so in an
> upcoming v2 patchset.
Cool.
Thanks,
pq
> > > + </interface>
> > > +
> > > +</protocol>
> >
> > That wording in one paragraph is the only thing I could hook onto,
> > otherwise this looks excellent. You have:
> >
> > Reviewed-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> >
> > regardless of whether the changes I proposed are done or not. I wonder
> > what Peter would think of my wording.
>
> Thanks,
> Alexandros
-------------- 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/20171218/ff13c3c2/attachment.sig>
More information about the wayland-devel
mailing list