[PATCH weston v3 3/3] Introduce wl_relative_pointer interface

[Jonas Ådahl]

On Thu, Oct 29, 2015 at 09:08:11AM +0000, Daniel Stone wrote:
> 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 ...)

The issue reported was that the motion deltas from the device had a
smaller value than wl_fixed_t could represent. For regular absolute
motions that could be fixed by accumulating the left over fraction and
appending it to the next motion.

We could do the same for relative motions, but then what would be the
point of having high precision timestamp but with low precision motion
delta?  Since the delta received is no longer, after the accumulated
fraction was appended, the one that came from the device at that point
in time.  If one actually do care about it, I'd expect one would want
the actual values as they came.

If we can be sure that the accumulated deltas are just as fine, I guess
we can drop the double fixed things and send them instead, but can we be
that sure? It's not really a big effort to send the whole deltas as two
uint32's, so if we are not sure I don't see any reason not to.


Jonas

> 
> Cheers,
> Daniel