Synaptic touchpad fails to register some of the taps for tap-to-click

[Valentin Neacsu]

Binary package hint: xserver-xorg-input-synaptics

When using tap-to-click, the synaptics driver fails to register some taps as clicks. I have managed to link this with abnormal coordinates reported by the driver using "synclient -m 10". Whenever a tap is not registered as a click, there is one or more consecutive reports of touching at coordinates (x=1, y=5855), which might explain why it is not registered as a click.

I have recorded a few taps and saved them as a .txt file, which you can view at: http://ubuntuforums.org/showpost.php?p=3202355&postcount=5

by watching the output of "synclient -m 10" I have been able to find a pattern, when taps are registered and when they're not. I have found that every time a tap is not registered there is a weird "1" appearing on the X column and a "5855" on the Y column, meaning that my touchpad registered touch at the (1,5855) coordinates. This, coupled with the MaxTapMove=220 (default), means that it will register a movement during my tap and as such it will invalidate it as a tap.

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
     Subsystem: Dell Unknown device [1028:01bd]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility X1400 [1002:7145] (prog-if 00 [VGA])
     Subsystem: Dell Unknown device [1028:2003]

[Valentin Neacsu (valentin.neacsu)]

Forgot to mention, my laptop is a Dell Inspiron 6400 with a Synaptics touchpad (verified in /proc/bus/input/devices):

I: Bus=0011 Vendor=0002 Product=0007 Version=0000
N: Name="SynPS/2 Synaptics TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/class/input/input3
H: Handlers=mouse1 event3 ts1
B: EV=b
B: KEY=6420 0 70000 0 0 0 0 0 0 0 0
B: ABS=11000003

My xorg.conf file:

Section "InputDevice"
 Identifier "Synaptics Touchpad"
 Driver "synaptics"
 Option "SendCoreEvents" "true"
 Option "Device" "/dev/psaux"
 Option "Protocol" "auto-dev"
 Option "SHMConfig" "on"

 Option "RTCornerButton" "0"
 Option "RBCornerButton" "0"
 Option "LTCornerButton" "0"
 Option "LBCornerButton" "0"

 Option "VertScrollDelta" "100"
 Option "HorizScrollDelta" "0"

 Option "MinSpeed" "0.09"
 Option "MaxSpeed" "0.18"
 Option "AccelFactor" "0.0015"
EndSection

[Pascal De Vuyst (pascal-devuyst)]

Thanks for your bug report, can you also attach the missing information described here: https://wiki.ubuntu.com/DebuggingTouchpadDetection.

[Valentin Neacsu (valentin.neacsu)]

If there's anything missing please let me know. Thanks.

[Valentin Neacsu (valentin.neacsu)]

Also, in case it helps, someone else filed a similar bug report over at debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437254

[Pascal De Vuyst (pascal-devuyst)]

You forgot the dmesg information.

[Valentin Neacsu (valentin.neacsu)]

Sorry about that. I must have overlooked it when attaching the files.

[Valentin Neacsu (valentin.neacsu)]

This bug has been confirmed on the Debian bug tracker. Check the link at the top for possible solution.

[Valentin Neacsu (valentin.neacsu)]

I think I have found a way around this bug. It's not pretty, and I must give credit for the idea to Nicolas Caval, the person who reported the same bug on the Debian bug tracker. He found a way around the bug for his needs, but it didn't work for me. Here's what I did to make it work:

1. apt-get source xserver-xorg-input-synaptics
2. sudo apt-get build-dep xserver-xorg-input-synaptics
3. cd xserver-xorg-input-synaptics*
4. gedit synaptics.c
5. go to line 1610, where you'll find:

    int timeleft;
    int i;

    /* update hardware state in shared memory */
    para->x = hw->x;
    para->y = hw->y;
    para->z = hw->z;

6. insert the following code right between the two blocks of code, so it looks like this:

    int timeleft;
    int i;

    /* this is crap, but it saves the day */
    if (hw->x == 1 && hw->y == 5855)
    {
        hw->numFingers = 0;
        hw->fingerWidth = 0;
        hw->z = 0;
        hw->x = HIST(0).x;
        hw->y = HIST(0).y;
    }

    /* update hardware state in shared memory */
    para->x = hw->x;
    para->y = hw->y;
    para->z = hw->z;

7. save & close the file
8. sudo dpkg-buildpackage
9. cd ..
10. sudo dpkg -i xserver-xorg-input-synaptics*.deb
11. restart X with CTRL+ALT+Backspace

[Pascal De Vuyst (pascal-devuyst)]

Valentin Neacsu,
Putting status back to Confirmed.
"Fix commited" means the changes are pending and to be uploaded soon or the fix is in CVS/SVN/bzr and shouldn't be used when a patch is attached to a bug. See https://wiki.ubuntu.com/Bugs/Status.

[Valentin Neacsu (valentin.neacsu)]

Whoops, sorry. I'm still new to this.

[Josh Schneider (josh68)]

Thank you, Valentin. This has worked well for me in Ubuntu on my e1505/6400. Though no one would solve this problem, as everyone was trying to address it through synclient tweaks.

[aachen (gopesh-24)]

Thanks a lot Valentin. It works well for me also. I am also using Dell inspiron 6400 with synaptics. I just installed ubuntu few days ago and found it wonderful but was about to delete it because of this annoying problem.

[Josh Schneider (josh68)]

Upgraded to Hardy, which has a new version of the synaptics xorg driver, and the problem returned. It still hasn't been fixed. I'm going to try the same workaround on the new driver soon.

[Valentin Neacsu (valentin.neacsu)]

The patch still works, but Update Manager constantly wants to replace the modified package with the original un-patched one. I'm attaching the patch so we could maybe see it included in future releases.

[Richard (z4nshin)]

Also a problem on a Medion MD96360. The patch works fine. I also filed a bug report and then I found this :). Thanks anyway. I hope they will fix this

[Nicolas Cavallari (batchman)]

No wonder why nobody wants to fix it. this drivers' code isn't really pretty. and upstream seems to be dead...

Can someone tests my less-hackish patch and see if it works ?

My touchpad seems to be faster than yours so it's more difficult to trigger this bug, but it seems to fix the problems for me.

[Josh Schneider (josh68)]

In Intrepid, this method of patching no longer works. There are 7 Ubuntu patches to the Debian source (I think), and if you manually patch synaptics.c, the deb won't build. I actually figured out a way around this once, and now I can't repeat it. Anyone?

Also, can anyone suggest how to pass this bug on to the xorg synaptics developers? I tried once with no responses. It's the same problem in every distro, and needs fixing at the source.

Thanks.

[Josh Schneider (josh68)]

Please ignore the first part of my last post. You can still patch, at least using the "hackish" version. However, I would also like to figure out a way to get this problem fixed upstream. Any help is appreciated.

[Nicolas Cavallari (batchman)]

If you tried to contact the old upstream ( http://web.telia.com/~u89404340/touchpad/ ) then it's dead. The project have since moved to xorg's git and this bug is fixed there.

[Josh Schneider (josh68)]

I don't remember what I tried, but I didn't get anywhere. The bug also isn't fixed on my laptop (Inspiron E1505/6400). In Intrepid, it behaves as it has since I first got this laptop, ignoring most taps in a way that isn't remedied through sensitivity adjustments.

[Nicolas Cavallari (batchman)]

The bug is fixed in Xorg's Git. Not in Ubuntu. (yet)

[Josh Schneider (josh68)]

Thanks for clarifying that.

On Wed, Dec 3, 2008 at 9:09 AM, Nicolas Cavallari <email address hidden> wrote:

> The bug is fixed in Xorg's Git. Not in Ubuntu. (yet)
>
> --
> Synaptic touchpad fails to register some of the taps for tap-to-click
> https://bugs.launchpad.net/bugs/133060
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Bryce Harrington (bryce)]

If I understand right, the git version mentioned in the last few comments as solving the issue is now released as 0.99.3 which we include in jaunty. So I'm guessing this issue is now resolved.

If I'm wrong, please feel free to reopen and I'll look into incorporating that patch. Thanks!

[Josh Schneider (josh68)]

I just did a clean install of Jaunty, and lo and behold, the problem is still there on my e1505/6400 Synaptics touchpad. I think a patch needs to be incorporated into the driver.

[Valentin Neacsu (valentin.neacsu)]

Marking as confirmed as per Josh Schneider's comment. I don't have the E1505/6400 any more so I can't test it out.

[Josh Schneider (josh68)]

FYI, obtaining the latest source, applying the patch, and rebuilding
per the instructions above still remedies the problem. Also, FYI, I am
running 64-bit, but I think that's not an issue.

On Sun, Apr 26, 2009 at 9:38 AM, Valentin Neacsu <email address hidden> wrote:
> Marking as confirmed as per Josh Schneider's comment. I don't have the
> E1505/6400 any more so I can't test it out.
>
> ** Changed in: xserver-xorg-input-synaptics (Ubuntu)
>       Status: Fix Released => Confirmed
>
> --
> Synaptic touchpad fails to register some of the taps for tap-to-click
> https://bugs.launchpad.net/bugs/133060
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Susan Cragin (susancragin)]

As of a couple of days ago, tapping on the mousepad no longer works on my ASUS G1S at all. Synaptics touch pad.

[Fernando Miguel (fernandomiguel)]

is https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/384968 a karmic regression on this ?

[Josh Schneider (josh68)]

If you consider an already malfunctioning driver totally losing a functionality, then maybe. The original problem here was poor tap-to-click behavior on specific touchpads, not NO tap-to-click functionality. Seems to be a driver with problems, though.

[William Grant (wgrant)]

On Mon, 2009-06-08 at 22:07 +0000, BUGabundo wrote:
> is https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-
> synaptics/+bug/384968 a karmic regression on this ?

No.

--
William Grant

[Josh Schneider (josh68)]

This will never be fixed, will it? Now in Karmic, the behavior is still less-than-great. I tried applying the patch to the latest driver, but I'm failing now to make a version that I can install. Anyone able to do this? Anyone know if this bug will ever be handled? Thanks.

[Josh Schneider (josh68)]

Just for giggles, I'm posting again in this thread. I'm finding that in Lucid (10.04), synaptics 1.2.2-1ubuntu4 is still no better in terms of accurately registering tap clicks, no matter how I tweak synclient settings. If anyone can walk me through a patch of this newer driver, it would be appreciated. I can no longer use my old patched version. Thanks.

[Kris (kmbroga)]

Josh, follow the steps given by Valentin Neacsu (posted 2007-09-01)
The file to modify is in xserver-xorg-input-synaptics-1.2.2/src/synaptics.c just after the line 2518 where it says:

 Bool inside_active_area;

 /* update hardware state in shared memory */
 if (shm)
 {
    shm->x = hw->x;
    shm->y = hw->y;
    shm->z = hw->z;
 ...

Now it should look like:

    Bool inside_active_area;

    if (hw->x == 1 && hw->y == 5855)
    {
        hw->numFingers = 0;
        hw->fingerWidth = 0;
        hw->z = 0;
        hw->x = HIST(0).x;
        hw->y = HIST(0).y;
    }

    /* update hardware state in shared memory */
    if (shm)
    {
        shm->x = hw->x;
        shm->y = hw->y;
        shm->z = hw->z;

It works for me and hopefully it will work for you.

[Josh Schneider (josh68)]

Thanks very much for the updated fix. I'll give it a try.

On Thu, Jun 3, 2010 at 5:44 AM, Kris <email address hidden> wrote:

> Josh, follow the steps given by Valentin Neacsu (posted 2007-09-01)
> The file to modify is in xserver-xorg-input-synaptics-1.2.2/src/synaptics.c
> just after the line 2518 where it says:
>
> Bool inside_active_area;
>
> /* update hardware state in shared memory */
> if (shm)
> {
> shm->x = hw->x;
> shm->y = hw->y;
> shm->z = hw->z;
> ...
>
> Now it should look like:
>
> Bool inside_active_area;
>
> if (hw->x == 1 && hw->y == 5855)
> {
> hw->numFingers = 0;
> hw->fingerWidth = 0;
> hw->z = 0;
> hw->x = HIST(0).x;
> hw->y = HIST(0).y;
> }
>
> /* update hardware state in shared memory */
> if (shm)
> {
> shm->x = hw->x;
> shm->y = hw->y;
> shm->z = hw->z;
>
> It works for me and hopefully it will work for you.
>
> --
> Synaptic touchpad fails to register some of the taps for tap-to-click
> https://bugs.launchpad.net/bugs/133060
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Josh Schneider (josh68)]

Well, the fix worked again, and I now have a patched x64 version of 1.2.2.
Thanks again.

FYI, on my end the patch applies at line 2090. There isn't even a line 2518
in that file. The difficulty for me (who doesn't really know what he's
doing) is tracking where the patch is placed as the driver is updated. Does
anyone know if this will ever just be incorporated in the driver itself, or
where I should go to request that? Previous posts said it had been fixed
upstream, but clearly it hasn't been. Also, it's not an Ubuntu or Debian
issue, but a universal problem for this touchpad (I'm assuming the same in
the e1405/e1505/e1705) in Linux (same poor functionality across distros).

On Thu, Jun 3, 2010 at 5:44 AM, Kris <email address hidden> wrote:

> Josh, follow the steps given by Valentin Neacsu (posted 2007-09-01)
> The file to modify is in xserver-xorg-input-synaptics-1.2.2/src/synaptics.c
> just after the line 2518 where it says:
>
> Bool inside_active_area;
>
> /* update hardware state in shared memory */
> if (shm)
> {
> shm->x = hw->x;
> shm->y = hw->y;
> shm->z = hw->z;
> ...
>
> Now it should look like:
>
> Bool inside_active_area;
>
> if (hw->x == 1 && hw->y == 5855)
> {
> hw->numFingers = 0;
> hw->fingerWidth = 0;
> hw->z = 0;
> hw->x = HIST(0).x;
> hw->y = HIST(0).y;
> }
>
> /* update hardware state in shared memory */
> if (shm)
> {
> shm->x = hw->x;
> shm->y = hw->y;
> shm->z = hw->z;
>
> It works for me and hopefully it will work for you.
>
> --
> Synaptic touchpad fails to register some of the taps for tap-to-click
> https://bugs.launchpad.net/bugs/133060
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Nicolas Cavallari (batchman)]

Well, seems that the problem got fixed, but another code was added that broke the thing again.

I bet those lines in synaptics.c:1473 ( in HandleTapProcessing() ) are responsible :

switch (priv->tap_state) {
[...]
    case TS_1:
        if (move) {
[...]
        } else if (release) {
            SelectTapButton(priv, edge);

/////// these ones ////////////
            /* Disable taps outside of the active area */
            if (!inside_active_area) {
                priv->tap_button = 0;
            }

but the inside_active_area calculation is made at line 2170 with the current value of hw->x and y, that is, the one that are no longer relevant (1,5855), so the assumption 'if there is no finger, there is no position' is violated.

can someone test removing the 'if (!inside_active_area) { priv->tap_button = 0; }' and see if this fix the problem ?

i'm gonna try it later, i don't have time now.

[Nicolas Cavallari (batchman)]

forget what i said in the previous post about the code, this is disabled by default.

[Nicolas Cavallari (batchman)]

Well, i think that the line just above is responsible : SelectTapButton(priv, edge);

it will detect that the tap is made in the bottom left corner, and by default, corner taps are disabled. hopefully, corner taps can be configured with your graphical interface or with xinput.

if you want to test if this applies to you, do :

# aptitude install xinput if that's not already installed
xinput list
# note the id of your synaptics device, for example, id=20
xinput set-props 20 "Synaptics Tap Action" 0 0 0 3 1 0 0

now tap in the middle of your pad. the taps that i think aren't recognized should now be recognized as right clicks. If that's the case, then this can be easily fixed, either use
xinput set-props 20 "Synaptics Tap Action" 0 0 0 1 1 0 0
to make those tap recognized as left clicks, or patch the source to add the line
edge = edge_detection(priv, priv->touch_on.x, priv->touch_on.y);
before SelectTapButton(priv, edge);

(note : the xinput command affects the mouse button to use under different tap configuration :
xinput set-props [ID] "Synaptics Tap Action" [RT] [RB] [LT] [LB] [F1] [F2] [F3]
[RT] is the mouse button to use when tapping on the right top hand corner
[RB] [LT] [LB] on the right bottom hand corner, left top hand corner, left bottom hand corner ...
[F1] tapping on the center with a single finger
[F2] tapping with two finger
[F3] tapping with three finger
0 disable the tap, 1 is the left button, 3 the right button and 2 the middle button.
)

[Josh Schneider (josh68)]

I finally got around to trying Nicholas' one-line patch, and so far, so good. Thanks for all your help.

I'm attaching my patch file. I created a patched amd64 deb, which I could also upload if anyone else wants to install. Don't have an x86 install to compile that, but I could upload all my files zipped if anyone wants that. I'm so bad on the command line, it takes me an hour just to follow instructions to patch and compile a driver from source!

[Bryce Harrington (bryce)]

Looking at the current upstream git tree for synaptics there's been a lot of changes, but it doesn't look like this particular bug has been fixed (near as I can tell anyway).

Nicolas' patch is tempting however I'm worried it would potentially affect behavior for non-bugged hardware too.

Fortunately, there's another approach. We can just set a quirk specifically for the Inspiron 6400, to implement Nicolas' workaround of treating left-bottom edge taps as left-button clicks. I *think* this should solve the issue, and won't risk breaking other hardware. (No code changes either!)

If you have an "Inspiron 6400" and version 1.2.2-2ubuntu6 does *not* fix it for you, please reopen this bug report.

If you have something other than an "Inspiron 6400" but think you have this same problem, please file a new bug report and attach your /proc/bus/input/devices file, like in comment #1. You can use this bug report as a guide on how to diagnose the problem (see especially comment #44). You can test if the quirk would fix your issue by creating an xorg.conf like in comment #1, and test setting the XXCornerButton options to 1 or 3.

We'll be moving to the 1.3.0 driver soonish in natty, probably within a month. Like I mentioned, it *might* have a fix for this issue but I can't be certain. If anyone gets the chance to test the upstream driver (or the one in Debian experimental currently) it would be great to hear your findings.

[Bryce Harrington (bryce)]

Regarding Nicolas' patch to do edge detection prior to calling SelectTapButton, to get that in I would suggest posting it to the xorg-devel mailing list on freedesktop.org for review first.

[Bryce Harrington (bryce)]

   * Add quirk for Dell Inspiron 6400 to register taps more reliably.
     The touchpad hardware occasionally sends invalid (1, 5855) coords
     for taps, which the driver then interprets as a corner tap, which
     by default get ignored. Instead of ignoring them, we treat them
     as left-button clicks.
     (LP #133060)

[To Do (entodoays)]

Hi,
I have a Dell Inspiron 6400 runnung ubuntu 10.10 and the xinput command solved the problem but I have to keep doing it once per session. I would like to make these settings permanent. I tried to edit the xorg.conf but the file doesn't exist.

Any ideas?

Thanks,

To

[Josh Schneider (josh68)]

This variation on the command worked for me:

<code>xinput --set-prop 12 "Synaptics Tap Action" 0 0 0 1 1 0 0</code>

[Josh Schneider (josh68)]

And it seems to have worked to just go to "System/Preferences/Startup Applications"and just create a new entry with this code in the Command line -- executes at boot.

[To Do (entodoays)]

That code works for me too except that the id is not always the same: sometimes it's 11 and sometimes it's 10. So I have to check each time with xinput list and then pass the xinput command.

I tried creating a partial xorg.conf with only the section for the touchpad but it doesn't seem to work.
My xorg.conf file:

Section "InputDevice"
 Identifier "Synaptics Touchpad"
 Driver "synaptics"
 Option "SendCoreEvents" "true"
 Option "Device" "/dev/psaux"
 Option "Protocol" "auto-dev"
 Option "SHMConfig" "on"

 Option "RTCornerButton" "1"
 Option "RBCornerButton" "1"
 Option "LTCornerButton" "1"
 Option "LBCornerButton" "1"

 Option "VertScrollDelta" "100"
 Option "HorizScrollDelta" "0"

 Option "MinSpeed" "0.09"
 Option "MaxSpeed" "0.18"
 Option "AccelFactor" "0.0015"
EndSection

[Nicolas Cavallari (batchman)]

I have been told that my patch to do edge detection with the initial touch position has been merged, but it's not pushed yet. Expect it to pop in the official tree anytime.

[Josh Schneider (josh68)]

That's great news. Thanks. I hope it actually does make it in, since this
bug has been out there for several years now.

On Wed, Feb 2, 2011 at 5:21 AM, Nicolas Cavallari <<email address hidden>
> wrote:

> I have been told that my patch to do edge detection with the initial
> touch position has been merged, but it's not pushed yet. Expect it to
> pop in the official tree anytime.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/133060
>
> Title:
> Synaptic touchpad fails to register some of the taps for tap-to-click
>