On Tue, 21 Nov 2017 18:20:08 +0200 Alexandros Frantzis <[email protected]> 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. Hi, 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. > > <snip> > > > + <!-- 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 > wp_presentation.presented. > > 2. Secondarily because it ~matches timespec, which is a standard posix > type. > > 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). Correct. > 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 > timestamps. 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. Thanks, pq
pgpU3NW_zKYtS.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
