protocol questions
Daniel Stone
daniel at fooishbar.org
Sat Mar 30 18:44:41 PDT 2013
Hi,
On 30 March 2013 16:55, Thiago Macieira <thiago.macieira at intel.com> wrote:
> On sábado, 30 de março de 2013 09.34.24, Matthias Clasen wrote:
> > > Monotonic (ideally) time in an undefined domain, i.e. they're only
> > > meaningful on relation to each other.
> >
> > What can you do with them ? For the use case that Giulio mentioned
> > (double-click detection), I'd need to know at least if the difference
> > between two times is seconds or milliseconds or microseconds...
>
> The protocol needs to specify the unit. It can't be dependent on the device
> driver, that makes no sense. If it's in milliseconds, it will overflow
> every
> 49.7 days. If it's microseconds, it will overflow every 71.6 minutes.
>
Yes, they are in milliseconds, I just explained it poorly.
> It also needs to specify which timestamps are in the same time domain. Can
> two
> timestamps be compared to each other only if:
>
> - they are in the same input device (same mouse, same keyboard), but not
> across devices
> - they are in the same seat, but not across seats
> - they are in input event messages, but not other types of messages that
> carry timestamps
> - no restriction
>
Personally, I think either #1 or #2. Definitely not #3 or #4. We want to
be able to use the evdev timestamps rather than gettimeofday() when we
receive it, so we can ensure that if someone clicks twice slowly, and the
compositor takes a while to process the same event, it's not interpreted as
a double-click.
> For example, imagine the case of trying to ensure that a Ctrl key was
> pressed
> before a mouse click happened, after the events were plucked out of the
> event
> stream.
>
> Or is there another, recommended way of doing that, such as by using the
> serials?
>
Hmmm. I was going to say using the event order, but it all depends on
which order the devices were read in. So I guess for this case we'd need
to go with #2.
Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130331/3c98300d/attachment.html>
More information about the wayland-devel
mailing list