On Thu, Oct 29, 2015 at 09:33:14AM +0000, Daniel Stone wrote: > Hi, > > On 29 October 2015 at 09:25, Jonas Ådahl <jad...@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 <jad...@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.
fwiw, I still read this bug as an issue of timestamp granularity, not motion granularity. unless I'm missing this, I can't find anything that says the deltas themselves are insufficient. and deltas are just that - device-specific deltas, and the raw motion isn't accelerated or normalized, so even a 8200 dpi mouse will give you a delta of 1/1 for the minimal movement. Even if we normalize those down to 1000dpi, the minimum delta is ca 1/8, and wl_fixed_t granularity is 1/256, right? Cheers, Peter _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel