[PATCH weston v3 3/3] Introduce wl_relative_pointer interface

[Jonas Ådahl]

On Fri, Oct 30, 2015 at 08:41:18AM +1000, Peter Hutterer wrote:
> On Thu, Oct 29, 2015 at 09:33:14AM +0000, Daniel Stone wrote:
> > Hi,
> > 
> > On 29 October 2015 at 09:25, Jonas Ådahl <jadahl at gmail.com> wrote:
> > > On Thu, Oct 29, 2015 at 09:08:11AM +0000, Daniel Stone wrote:
> > >> 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.
> > 
> > Right, so I think we agree here. I'd prefer to keep the types matching
> > as well; I do struggle to see how wl_fixed_t isn't sufficient, but on
> > the other hand am not entirely sure I care enough about it, so am
> > happy with whichever. Keeping it purely raw might in fact just be
> > easier for everyone.
> 
> fwiw, I still read this bug as an issue of timestamp granularity, not motion
> granularity. unless I'm missing this, I can't find anything that says the
> deltas themselves are insufficient.
> 
> and deltas are just that - device-specific deltas, and the raw motion isn't
> accelerated or normalized, so even a 8200 dpi mouse will give you a delta of
> 1/1 for the minimal movement. 
> Even if we normalize those down to 1000dpi, the minimum delta is ca 1/8, and
> wl_fixed_t granularity is 1/256, right?

That is true. Where we might have even smaller values would be if we
normalize to 1000dpi and apply pointer deceleration, but then we still
wouldn't end up with such small values because usually the smallest
factor we decelerate with is 0.3, meaning we still wouldn't end up with
that small deltas. We discussed this on IRC, and after your
explanations, I think we could just as well just use wl_fixed_t. If
there would be acceleration profiles that decelerate even more (for
example 0.03 instead of 0.3 on a 8200dpi mouse normalized to 1000dpi),
then since the resulting delta doesn't really represent a hardware event
anyway, accumulating the leftover fraction isn't that big of a deal.
Daniel, what do you think?


Jonas

> 
> Cheers,
>   Peter