[ANNOUNCE] predictable pointer acceleration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello list,

predictable pointer acceleration in X has arrived. Enjoy!

'Predictable' refers to one's ability to tell where the pointer will
move - even in the presence of acceleration. That wasn't really given
before.

The main features:
      * user-selectable profiles control pointer acceleration
      * adaptive and constant deceleration
      * acceleration becomes predictable
      * no overshoot when X blocks for a short time

To sum it up, it's all about useability and adaptability to a wide range of relative pointing devices.

I would like to propose it for inclusion in X server 1.6. If no-one
objects, I'll add it on the wiki.

More information is available here:
http://www.x.org/wiki/Development/Documentation/PointerAcceleration

It is intended to be a drop-in replacement, so if you didn't note it,
fine. Lookup the wiki to see how to benefit. Care has been taken to make the transition smooth, and the previous method is retained as an option to provide full compatibility. If any problems occurred, please let me know!

Acknowledgements go to to Peter Hutterer for his great support and generally getting it in shape, and to Daniel Stone who picked up on it initially. Thanks also to all the others who provided their insights on various issues.


For those who care (do you have a mouse?), here are some topics that
I think deserve some broader discussion:

   * By default, the benefits fall short of what's possible. Therefore
I propose changing the acceleration defaults so polynomial acceleration
comes to effect, with adaptive deceleration = 2. The first patch does that. Everyone on git master can test-drive the effect using 'xset m 2 0' and setting adaptive deceleration (see the snippet below or in the wiki). Drawback: It's not too useable for people who switched back to the lightweight scheme.

   * I introduced a 'Driver API', which lets a device driver speak up
on some acceleration and scaling related issues. E.g. it could suppress
acceleration since it does its own, or provide some information to
improve results. The wiki has more details. The second attachment contains my proof-of-concept. So driver people: Is it reasonable? Would you use it?

  * The algorithm has numerous tweaks, and the defaults are pretty much
'my hardware + common sense'. Someone with more insight in hardware
variability should look at them.


Some points for future developments:

  * The information maintained to make this possible, i.e. sub-pixel
position and velocity, is of some use further down the chain. For
example, sub-pixel movement might be interesting in scroll bars, or a
widget might suppress extensive gfx effects if the velocity of the
pointer indicates that it's a spurious hit only. This would require
an input event rework and more or less dropping the lightweight scheme.

   * The code could further improve blocking cases using better
timestamps, such as evdev delivers. However, they can't be passed to DIX
at the moment. Moreover, Tiago's input thread could have a practically
equivalent effect. This would be strictly optional anyway since most
sources don't do timestamps. Opinions?

   * The velocity estimation (=reference for acceleration) is a separate
issue, but currently not implemented completely separate. I haven't seen
a realistic need to exchange it, but if anyone convinces me I might look into it. Reasons could be devices with speed sensors or devices which are unsuitable somehow for the present algorithm. Make your case.


Still reading? OK, here's a goodie: if you place the below snippet in your .fdi or put up an equivalent xorg.conf section, the velocity estimate will likely improve. When using a sane profile, i.e. not the simple default thing, this will further improve smoothness.

<match key="info.capabilities" contains="input.mouse">
<merge key="input.x11_options.AdaptiveDeceleration" type="string">2</merge>
  <merge key="input.x11_options.FilterHalflife" type="string">5</merge>
  <merge key="input.x11_options.FilterChainLength" type="string">8</merge>
<merge key="input.x11_options.VelocityCoupling" type="string">0.15</merge>
</match>

I'd make it the default but it is computationally more intensive, and simple profile users (the majority, I guess, since that was the only actually useable thing before) do not really benefit. If we were determined to get out the max, this would be the way to go however.

Have Fun!

- Simon Thum


>From 55544930ee02fbc1a2198e32e97c4d6ff6f6d9d9 Mon Sep 17 00:00:00 2001
From: Simon Thum <simon.thum@xxxxxx>
Date: Sun, 10 Aug 2008 19:11:21 +0200
Subject: [PATCH] dix: make polynomial pointer acceleration the default

to make better use of the new pointer acceleration code,
polynomial acceleration is now default.
---
 dix/ptrveloc.c |    2 +-
 include/site.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/dix/ptrveloc.c b/dix/ptrveloc.c
index 983df4b..44d600f 100644
--- a/dix/ptrveloc.c
+++ b/dix/ptrveloc.c
@@ -106,7 +106,7 @@ InitVelocityData(DeviceVelocityPtr s)
     s->last_dx = 0;
     s->last_dy = 0;
     s->use_softening = 1;
-    s->min_acceleration = 1.0; /* don't decelerate */
+    s->min_acceleration = 0.5; /* allow some deceleration */
     s->coupling = 0.25;
     s->average_accel = TRUE;
     s->profile_private = NULL;
diff --git a/include/site.h b/include/site.h
index fec8707..d891815 100644
--- a/include/site.h
+++ b/include/site.h
@@ -110,7 +110,7 @@ SOFTWARE.
 
 #define DEFAULT_PTR_NUMERATOR	2
 #define DEFAULT_PTR_DENOMINATOR	1
-#define DEFAULT_PTR_THRESHOLD	4
+#define DEFAULT_PTR_THRESHOLD	0
 
 #define DEFAULT_SCREEN_SAVER_TIME (10 * (60 * 1000))
 #define DEFAULT_SCREEN_SAVER_INTERVAL (10 * (60 * 1000))
-- 
1.5.6.4






diff --git a/src/mouse.c b/src/mouse.c
index 52bd6e0..7c605bf 100644
--- a/src/mouse.c
+++ b/src/mouse.c
@@ -70,6 +70,8 @@
 #include "xf86_OSproc.h"
 #include "xf86OSmouse.h"
 
+#include "ptrveloc.h"
+
 #ifndef NEED_XF86_TYPES
 #define NEED_XF86_TYPES	/* for xisb.h when !XFree86LOADER */
 #endif
@@ -1804,6 +1806,25 @@ MouseProc(DeviceIntPtr device, int what)
 	    RegisterBlockAndWakeupHandlers (MouseBlockHandler, MouseWakeupHandler,
 					    (pointer) pInfo);
 	}
+
+	/**
+	 * setup dix accel to avoid configuration redundancies
+	 */
+	DeviceVelocityPtr pVel = GetDevicePredictableAccelData(pInfo->dev);
+	mPriv = (mousePrivPtr)pMse->mousePriv;
+	if(pVel){
+	    if(pMse->sampleRate > 0){
+		pVel->corr_mul = 1000.0f/(float)pMse->sampleRate;
+		xf86Msg(X_INFO, "%s: setting velocity scale from sample rate: %.2f\n",
+			    pInfo->name, pVel->corr_mul);
+	    }
+	    if(pVel && mPriv && mPriv->sensitivity){
+		xf86Msg(X_INFO, "%s: postponing sensitivity\n",
+			    pInfo->name);
+		pVel->const_acceleration *= mPriv->sensitivity;
+		mPriv->sensitivity = 1.0;
+	    }
+	}
 	break;
 	    
     case DEVICE_OFF:





_______________________________________________
xorg mailing list
xorg@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/xorg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [X Forum]     [Intel Graphics]     [AMD Graphics]     [Nouveau Driver]     [XFree86]     [XFree86 Newbie]     [IETF Annouce]     [Security]     [Fontconfig]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Video for Linux]     [Linux RAID]

  Powered by Linux