[PATCH weston v3 3/3] Introduce wl_relative_pointer interface

[Daniel Stone]

Hi,

On 29 October 2015 at 06:54, Jonas Ådahl <jadahl at gmail.com> wrote:
> On Thu, Oct 29, 2015 at 02:58:33PM +1000, Peter Hutterer wrote:
>> mostly thinking aloud here:
>> The precision that humans can consciously control a mouse with is very high.
>> Whether 24.8 is insufficient for *us*, I'm not sure.
>> Maybe leave it at wl_fixed_t for now and figure out a transition plan for
>> making this a latched event in the style of the wl_pointer.axis_discrete
>> proposal, if we ever need it?
>>
>> i'd stick with the 64-bit timestamps though, we know we have devices out
>> there that exceed the current granularity.
>
> Except that if we use 64 bit timestamps with 32 bit wl_fixed_t, the
> timestamps would not represent actual movement anyway since it doesn't
> fit in a wl_fixed_t[0]. That was the point of the 64 bit fixed point deltas
> from the beginning wasn't it?

The main issue I can see in that bug is that you can't accurately
correlate button to motion due to timestamp granularity, i.e. if you
have sub-millisecond timings on motion but not on button, then where
did the button land?

Except that I can't really see how it's a problem. We guarantee an
ordered event stream: you don't need to reconstruct where the button
event was, because it is exactly where it was delivered. The only way
you can botch this is if your button and relative events end up in two
separate event queues, but given that you need to manually correlate
the two anyway (i.e. record position in your relative-motion handler,
and then query that position from your button handler), then I don't
see it as being a valid usecase.

Is there something I'm missing here? (I often get the feeling there is
with high-precision/report motion ...)

Cheers,
Daniel