mouse pointer no longer has 1 pixel precision

I can confirm that this bug is a problem, and only affects Jaunty, not Intrepid. My touchpad is an ALPS type touchpad. In an effort to fix it on my own system, I tried a few things. You can't fix it using xinput, synclient, xset, or other common terminal commands. I also tried altering the relevant .fdi files for the HAL.

I tried using an external mouse, and it worked flawlessly, so it's definitely a problem with the synaptics driver. I tried running Intrepid through LiveUSB on the same system, and the touchpad works flawlessly there.

My laptop, which is being affected by this bug, has a 1440x900 screen. Using "xinput query-state", I was able to confirm that, in Intrepid, the touchpad allows for coordinates from 0,0 to 1439,899. I was also able to confirm that, in Jaunty, it only allows for coordinates up to 1023,767 (representing the bottom-right corner of the screen). This indicates that there is a problem with the resolution that the touchpad is being set up to register.

I also tried copying the relevant .fdi file from the LiveUSB version of Intrepid over to Jaunty - no good. Same problem, the only change was the ID given to the touchpad for xinput purposes. The only other hint is that, in Intrepid, the "max_value" values for the touchpad are set to -1 for both axes, but they're set to 1023 and 767 in Jaunty.

Problem is, for all my searching, I can't find a place, anywhere, to change the "max_value" numbers for each axis of the touchpad, so as a result I can't get the touchpad to correct itself to the appropriate "resolution". I can only think that either there's a mistake making the driver incorrectly detect the resolution, or someone forgot to document an added functionality making the resolution a manual input rather than automatically detected. Other mentions I've seen of this issue around the net (only a few instances) all seem to indicate the "max_value"s are set to 1023 and 767.

Yes, thats definitely it. I have the same thing. My resolution is 1920x1200 but the max values are 1023 and 767. I have an ALPS Glidepoint touchpad (as reported by 'xinput list') on a Dell Latitude D830.

I have upgraded to Karmic since this bug was filed and it still exists.

OK, I've determined exactly which update actually caused the problem. It was the one that took it up from 0.15.2 to 0.99.3. By forcing it to use the 0.15.2-0ubuntu8 version, I regain proper precision (although mouse speed is significantly lower - probably would require tweaking).

I'll see if I can figure out what actually caused the problem, but I'm no driver programmer (I'm a mathematician, the language I'm most proficient in is MatLab).

To reproduce:
Start Gimp and create a new document.
Move the mouse cursor slowly horizontally and watch the column number change. The column number skips every 3rd or 4th pixel . i.e. 9,11,12,14,15,16,18,19,21. The cursor appears a bit jumpy due to the discontinuities.

If xserver-xorg-input-synaptics is uninstalled such that the mouse driver handles the touchpad, the cursor does not exhibit this behavior, moving smooth as silk and able to move to every pixel.

Behaves this way in many versions of xserver-xorg-input-synaptics including all Jaunty versions and the latest.(corresponding to git tag xf86-input-synaptics-1.1.0)

Running 2.6.29-02062904-generic 64 bit kernel on Jaunty.

I can confirm that I have the exact same problem. Removing xserver-xorg-input-synaptics fixes the problem but now, of course, I don't get any touchpad features (scrolling, tapping, etc.)

Aielyn, can you give some more details on your workaround? How did you revert to the 0.15.2 package?

nxmehta - I don't recall all of the finer details, but what I do remember is this:

https://launchpad.net/ubuntu/+source/xfree86-driver-synaptics/0.15.2-0ubuntu8

choose your build (probably i386, as mine is, or amd64, as with botlobsta), and download the deb. Uninstall the current xserver-xorg-input-synaptics if you currently have it installed, then install the aforementioned deb file. It will show up in synaptics as xserver-xorg-input-synaptics. You will undoubtedly want to select "Lock Version" on it once it's installed, otherwise it will constantly bug you to update to the current, broken version.

There are more steps to get it working really well, most involving setting up the .fdi file so that HAL makes the touchpad behave the way that you want - the first thing you'll probably want to change is the speed of the mouse.

Meanwhile, I looked through what I could of the source code and the diff for the 0.99.3 version, but was entirely unable to see anything hinting at why this problem exists at all. But then, it's probably really obvious, and I just don't see it due to lack of experience.

I downloaded the Karmic Live CD, and I've run it - this problem is still there. Hasn't been fixed.

I haven't tried testing to see if it can now be fixed by various command line tools, config files, etc, but I'll do that soon - I don't have much hope, though, because the behaviour is identical to what was seen with Jaunty. I'll test soon, and then I'll see if the older Jaunty version that worked properly (as I described in previous comments) works in Karmic.

I can now confirm that the older Jaunty driver I mentioned in #7 still works with Karmic.

Oh dear, the problem still hasn't been fixed, and it seems that the downgrade no longer works with Lucid Lynx. When trying to install the old driver, it complains that it conflicts with xserver-xorg-core because it contains xserver-xorg-input-4.

This is now, as of 10.04, a problem that has no known (temporary) fix!

I can confirm that this bug still exists in Lucid. This is a huge problem for people with ALPS touchpads! How can we get someone involved who will be able to fix this?

I'm not totally sure, but this might be tied to an upstream bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576211

It looks like there's a patch attached. Might be worth trying to apply the patch and install a patched version of the driver...

Nikil, thanks. Now that I look through the diff between the last working version and the first non-working one, I find that this is indeed where the problem is.

Here's the relevant part of xfree86-driver-synaptics_0.15.2-0ubuntu8_0.99.3-1ubuntu1.diff

@@ -711,11 +782,18 @@
 #endif
        );
     /* X valuator */
- xf86InitValuatorAxisStruct(dev, 0, 0, -1, 1, 0, 1);
+ if (priv->minx < priv->maxx)
+ xf86InitValuatorAxisStruct(dev, 0, priv->minx, priv->maxx, 1, 0, 1);
+ else
+ xf86InitValuatorAxisStruct(dev, 0, 0, -1, 1, 0, 1);
     xf86InitValuatorDefaults(dev, 0);
     /* Y valuator */
- xf86InitValuatorAxisStruct(dev, 1, 0, -1, 1, 0, 1);
+ if (priv->miny < priv->maxy)
+ xf86InitValuatorAxisStruct(dev, 1, priv->miny, priv->maxy, 1, 0, 1);
+ else
+ xf86InitValuatorAxisStruct(dev, 1, 0, -1, 1, 0, 1);
     xf86InitValuatorDefaults(dev, 1);
+
 #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) == 0
     xf86MotionHistoryAllocate(local);
 #endif

As you'll notice, the 0.15.2 version always set the min and max values for both axes to 0 and -1, respectively, whereas the 0.99.3 version set it to the touchpad's values, which is the cause of the problem. The fact that this change happened at the precise time that this problem first started suggests that this is, indeed, the flaw.

If someone can talk me through how to apply the patch, I'll be happy to test it to confirm that it fixes the problem. Problem is, I've no experience doing patches, or compiling from source for that matter, so I don't know what I need to do.

What I've done so far is downloaded the source files, as well as the xserver-xorg-input-synaptics-dev package. I'm afraid that's as far as I've gotten so far.

I tested the patch from the debian bug report and it works on lucid with xserver-xorg-input-synaptics version 1.2.2. How do we get this patch applied to the repository?

OK, I figured out how to patch for myself, and I've tested it. BotLobsta has confirmed for amd64, I'm now confirming it for i386.

Here's the diff file that you use for the patching.

OK, now it's getting absurd. It *still* hasn't been fixed in Maverick. Fortunately, the same patch works in the Maverick version as it does in the Lucid one, but come on - this problem has an identified cause, a known temporary solution (which does correct the problem, it's not just a workaround)... how has it not been addressed in the official version yet?

If the problem is in identifying when the correction needs to work, can't a simple file be introduced that allows users to set the appropriate values, should they find that the defaults not be acceptable? Just a config file that, if absent, leaves everything at defaults?

The problem being seen in this bug report is limited to specific hardware with touchpads with height/width ratios significantly different from the monitor, which seems to be a pretty rare situation. That patch disables scaling behavior across the board, which would cause undesirable change in functionality for the vast many touchpads that *are* working correctly.

However, the diagnosis done by Aielyn is sound, it just needs a more sophisticated patch.

I've coded up this patch which adds a configurable option to disable the touchpad resolution detection functionality. With this turned on it should have the same effect as Aielyn's patch. This way, we can use this workaround only on hardware that requires it.

This bug was fixed in the package xserver-xorg-input-synaptics - 1.2.2-2ubuntu7

---------------
xserver-xorg-input-synaptics (1.2.2-2ubuntu7) natty; urgency=low

  * Add 116_resolution_detect_option.patch: Provide an option to prevent
    synaptics from communicating the touchpad size to the xserver. This
    can be used to solve problems where differences in touchpad and screen
    dimensions cause the mouse pointer to skip pixels when moving.
    (LP: #327428)
 -- Bryce Harrington <email address hidden> Wed, 01 Dec 2010 17:03:44 -0800

I've committed a fixed up version of the patch to natty. I can't reproduce the original problem on my hardware so cannot test it, but I think it's correct.

This adds an xorg.conf option ResolutionDetect, which is turned on by default. You can set it off in order to work around this bug.

I also added it as an xinput property so you should be able to flip it on or off using the usual xinput syntax.

It is also possible to set X up to apply this setting automatically for this specific hardware via xorg.conf.d. However, to do that we have to know what your hardware *is*. If you test this option and find it solves the problem on your hardware, please post your /proc/bus/input/devices file and re-open this bug report and we can craft an appropriate rule for your HW.

Frustratingly, it looks like your fix has been removed from 1.3.99. Unless I'm reading the source code incorrectly, which is possible. I'm looking at the patch, and looking for evidence of it within the source code... nothing.

Yep, looks like the patch got dropped. Reopening.

[I've marked this bug for inclusion in our oneiric bug queue. While technically this bug has not been re-confirmed against oneiric, I feel it is worth continued development attention. We will need to ask that it be re-confirmed once oneiric is further along, perhaps once we get closer to alpha.]

This bug was fixed in the package xserver-xorg-input-synaptics - 1.3.99+git20110116.0e27ce3a-0ubuntu13

---------------
xserver-xorg-input-synaptics (1.3.99+git20110116.0e27ce3a-0ubuntu13) oneiric; urgency=low

  * Re-add 116_resolution_detect_option.patch as 101_resolution_detect_option.patch:
    - This patch was introduced in 1.2.2-2ubuntu7 but got erroneously dropped in the
      merge for 1.3.99+git20110116.0e27ce3a-0ubuntu1.
      (LP: #327428)
 -- Bryce Harrington <email address hidden> Fri, 20 May 2011 11:14:44 -0700

I've downloaded the Oneiric build of xserver-xorg-input-synaptics (note: I discovered that my laptop can handle 64-bit, so I'm now using the AMD64 version of Ubuntu), and it works fine in Natty. And yes, it does resolve the problem. Before, when viewed using "xinput query-state", with the cursor in the bottom-right corner, it would read 1023 and 767, now it reads (currently dual screening) 2463 and 899, which is just right.

Thank you, Bryce.