[PATCH weston v3 3/3] Introduce wl_relative_pointer interface

[Daniel Stone]

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?

Cheers,
Daniel