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. 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). 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. Thanks, Alexandros _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
