>> - While the protocol and the library support subpixels, the server doesn't >> > actually send them down the wire yet. > > Any reason that scaled input devices can't do this? It seems like some > fairly important new functionality that would be nice to see > demonstrated. > Attached is a patch which enables the axis remainder from relative motion to be used*. This makes sense especially with adaptive deceleration. Should be easy to adapt to rescaleValuatorAxis output (more or less copy from accelPtrPredictable) so absolute is covered too.
One that's done one can fill a fp16.16 using axis and remainder. Note the remainder is -0.5..0.5 ATM. Cheers, Simon (*) Just ignore the deleted comment, rounding is covered
>From 29acbb0ddc4a2bfdb8599dda769e4db0468f5b47 Mon Sep 17 00:00:00 2001 From: Simon Thum <[email protected]> Date: Sat, 21 Mar 2009 18:19:19 +0100 Subject: [PATCH] dix: allow relative motion buffer to accumulate in a natural way since with XI2 we pass sub-pixel motion, anything else is broken. --- dix/ptrveloc.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/dix/ptrveloc.c b/dix/ptrveloc.c index 02089ff..4ee8589 100644 --- a/dix/ptrveloc.c +++ b/dix/ptrveloc.c @@ -968,12 +968,6 @@ acceleratePointerPredictable( if (dx || dy){ /* reset non-visible state? */ if (ProcessVelocityData2D(velocitydata, dx , dy, evtime)) { - /* if nv-reset: set to center of pixel. - * makes sense as long as there are no means of passing on - * sub-pixel values to apps(XI2?). If you remove it, make - * sure suitable rounding is applied below. - */ - pDev->last.remainder[0] = pDev->last.remainder[1] = 0; soften = FALSE; } -- 1.6.0.6
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
