Simon Thum wrote: > Simon Thum wrote: >> Peter Hutterer wrote: >>> On Mon, Jun 22, 2009 at 07:13:12PM -0400, Thomas Jaeger wrote: >>>> typedef void (*PointerAccelSchemeProc)( >>>> DeviceIntPtr /*pDev*/, >>>> int /*first_valuator*/, >>>> int /*num_valuators*/, >>>> int* /*valuators*/, >>>> float* /*x_frac*/, >>>> float* /*y_frac*/, >>>> int /*evtime*/ >>>> ); >>> >>> punting this to simon (cc'd) >> A good idea at first glance; I aligned to the scheme modifying >> valuators and remainder in-place simply because that is how it was >> done. But, aside for being cleaner in some way, what does it buy us? >> It's also harder to optimize the no-op case since you always need to >> copy back. > Crap, I missed you could still do in-place of course, so this last thing > is not a valid argument. Still, I'd prefer a more general solution as > advertised in the previous mail.
Taking non-accelerated code-paths (and crossing sctreens) into account, it seems the most sensible place to set dev->last.remainder[...] is positionSprite, so in-place modification doesn't buy us anything. > Also, if we have a pointer to axes we could strip first_valuator as we > could as well modify the pointer and num_valuators. But TBH I don't even > know first_valuators raison d'ĂȘtre. I was able to uncover 2(!) obscure > sites (vuidFlushAbsEvents in sun_mouse.c and one in jstk.c) where it > could get non-zero under circumstances. In contrast, the server is > stuffed with non-obvious logic(to me, at least) depending on it. There's probably still a few hidden bugs related to first_valuator (I found two during the last couple weeks). But some drivers actually perform the questionable optimization of setting first_valuator to 1 if the x-coordinate doesn't change, which causes xserver-1.6 (I haven't tested this on master) to report incorrect coordinates in XI events (http://sourceforge.net/tracker/?func=detail&atid=1078454&aid=2807915&group_id=229797). So I'd be very happy with getting rid of first_valuator, but I still don't quite see how you would want to do that. Tom _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
