[PATCH weston v3 3/3] Introduce wl_relative_pointer interface

[Daniel Stone]

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.

Cheers,
Daniel