[PATCH weston v3 3/3] Introduce wl_relative_pointer interface

[Peter Hutterer]

On Thu, Oct 15, 2015 at 09:45:56AM +0100, Daniel Stone wrote:
> Hi,
> 
> On 15 October 2015 at 09:32, Jonas Ådahl <jadahl at gmail.com> wrote:
> > On Thu, Oct 15, 2015 at 09:16:14AM +0100, Daniel Stone wrote:
> >> On 15 October 2015 at 04:56, Jonas Ådahl <jadahl at gmail.com> wrote:
> >> > On Thu, Oct 08, 2015 at 12:15:10PM -0500, Derek Foreman wrote:
> >> >> Perhaps I should read what's in phabricator before I continue to
> >> >> comment, though.
> >> >
> >> > Hmm. I can't find it any more. It was in the fdo phabricator task
> >> > <https://phabricator.freedesktop.org/T1> but all those comments are no
> >> > longer there. I have no idea why.
> >>
> >> Hmm, is it in the individual commits for review?
> >>
> >> e.g. https://phabricator.freedesktop.org/D13
> >
> > "You Shall Not Pass: Restricted Differential Revision"
> 
> Oops. Given that was the first revision (D1!) ever in there, it was
> against an old repository import that I later junked. Phabricator got
> confused since it partly inherits the permission from the repository -
> fixed now. As you can probably guess from all the spam in your inbox
> ...
> 
> >> > I wonder if we should put "wl_double_fixed" in wayland/ and declare that
> >> > an "official mutli part type" thing so we don't have to reimplement the
> >> > awkward from/to functions all over the place. Maybe even
> >> > a wl_double_fixed_t type as was suggested at an earlier point?
> >>
> >> I'm still a bit uneasy on the actual need for this: wl_fixed_t gives
> >> us 1/256th-pixel precision. Is that not enough? Surely changes less
> >> than that cannot affect the viewport, so why would we spam clients
> >> with them rather than accumulating internally and sending when it
> >> passes the threshold? Is it just about implementing acceleration on
> >> the client side?
> >
> > For absolute motions I agree. For relative, I don't know. I'm no high
> > end gaming device expert (or where high precision might be relevant)
> > There were discussions about this before that resulted in changing
> > from ms to us timestamps and from 32 bit to 64 bit fixed for deltas,
> > because we didn't want to pretend to be sure that the precision we had
> > was definitely enough for all relative pointer use cases.
> 
> Ack, fair enough. Anyone?

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.

Cheers,
   Peter