Hi, On 29 October 2015 at 06:54, Jonas Ådahl <[email protected]> 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 ...) Cheers, Daniel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
