[PATCH weston v3 3/3] Introduce wl_relative_pointer interface

[Peter Hutterer]

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?

Cheers,
  Peter