[PATCH wayland-protocols] unstable: Add input-timestamps protocol

Pekka Paalanen ppaalanen at gmail.com
Mon Dec 18 12:33:44 UTC 2017 

On Mon, 18 Dec 2017 13:53:28 +0200
Alexandros Frantzis <alexandros.frantzis at collabora.com> wrote:

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

That is again slightly different, but also reasonable.

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

The downsides are true. Our discussion proves that it is hard to write
down in a concise form.

I would be less optimistic about ever getting to v2, as once this
works, such minor details become insignificant. No matter, the cases
where this would save bandwidth are likely scarce.


Thanks,
pq

> > > 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>
-------------- 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/967f86c3/attachment.sig>

More information about the wayland-devel mailing list