[PATCH wayland-protocols] unstable: Add input-timestamps protocol
Alexandros Frantzis
alexandros.frantzis at collabora.com
Mon Dec 18 11:53:28 UTC 2017
On Mon, Dec 18, 2017 at 12:50:30PM +0200, Pekka Paalanen wrote:
> 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
Hi Pekka,
> > > > + <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.
Thanks for the additional clarification. I did indeed misunderstand your
proposal. I think what your propose makes sense as a potential
optimization. So, another way to put this would be that the high-res
time value from a timestamp event is associated with all input events
(with timestamps) from the specified input object until either 1. a new
timestamp event arrives or 2. a group/frame event arrives in which case
the timestamp value will be effectively invalidated.
I am inclined to not include this in unstable_v1, though, since it does
add some slight complication to both the protocol wording and the
protocol implementation (but it all depends on the particular design).
As we gain more practical experience with this protocol and the
potential overhead of timestamp events we could certainly reconsider
this and other optimizations in a future unstable_v2.
> > 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
Thanks,
Alexandros
More information about the wayland-devel
mailing list