On Wed, 13 Dec 2017 16:48:28 +0200 Alexandros Frantzis <alexandros.frant...@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.frant...@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.frant...@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.frant...@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.paala...@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
pgpEycV2lzQcM.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
