Hi, On 29 October 2015 at 09:25, Jonas Ådahl <[email protected]> wrote: > On Thu, Oct 29, 2015 at 09:08:11AM +0000, Daniel Stone wrote: >> 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 ...) > > 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
