[PATCH weston v3 3/3] Introduce wl_relative_pointer interface

[Jonas Ådahl]

On Thu, Oct 15, 2015 at 09:16:14AM +0100, Daniel Stone wrote:
> Hi,
> 
> 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:
> >> On 07/10/15 07:41 PM, Jonas Ådahl wrote:
> >> > On Wed, Oct 07, 2015 at 01:32:35PM -0500, Derek Foreman wrote:
> >> >> Would really like to see Daniel's review, time permitting.
> >> >>
> >> >> I think it would be nice to land this in the same release cycle (ie:
> >> >> this one) as pointer confinement, because I think the two features
> >> >> really go hand in hand.
> 
> Ahem, yes. Week o' meetings this week, but then straight back on it. :\
> 
> >> > Initially this request took a seat, since then it has been more
> >> > considered an extension to the pointer object (sharing its focus, etc)
> >> > than its own seat device. It was brought up during an early review (on
> >> > phabricator, so you might not have seen it) that it might be a good idea
> >> > to make the extension-ness more obvious.
> >>
> >> I can't find any of this in phabricator - can you give me a url?  Maybe
> >> I'm just doing a poor search...
> >>
> >> > An besides that, the client will probably want to know the pointer
> >> > focus, it might want to set the cursor and it will probably like to know
> >> > about clicks etc.
> >>
> >> But if it's a 1000hz gaming mouse the compositor will generate 1000
> >> events per second for the client to discard?
> >>
> >> Why not just allow the pointer to be bound as either/both serial and
> >> absolute, and have each be a fully functional interface?
> >>
> >> 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"

> 
> >> >>> + wl_double_fixed_from_double(dx, &dx_int, &dx_frac);
> >> >>> + wl_double_fixed_from_double(dy, &dy_int, &dy_frac);
> >> >>
> >> >> Do you have a patch somewhere for wl_double_fixed_from_double?
> >> >
> >> > http://patchwork.freedesktop.org/patch/49211/
> >>
> >> Ah, yes, hung up indefinitely in the pointer confinement review. :/
> >>
> >> It would be nice to unstick some of the preamble bits that require less
> >> fisticuffs than the protocol bits...
> 
> Agreed. There are a good number of preamble commits which did look
> good (see the green-tick ones linked from T1), which I think we should
> just go ahead and merge. If there are any follow-ups that need my
> attention, please ping me and I can do them very very quickly.
> 
> > 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.


Jonas