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