XOrg-Driver-Synaptics - synaptics driver for XOrg

Mouse cursor jumps when two fingers are used

Reported by Alberto Milone on 2009-04-24
104
This bug affects 21 people
Affects Status Importance Assigned to Milestone
XOrg-Driver-Synaptics
Fix Released
Medium
xserver-xorg-input-synaptics (Ubuntu)
Medium
Alberto Milone

Bug Description

Binary package hint: xfree86-driver-synaptics

If the user touches the touchpad in two locations, then raises the first finger that touched the pad, the mouse jumps to the location of the second finger as if a full move occurred. This happens on Synaptics touchpads.

To reproduce:
Touch the pad in the upper right and hold
Touch with another finger lower left and hold
Release the finger in the upper right
Mouse jumps to lower left edge of the screen, sometimes selecting text along the way

Changed in xfree86-driver-synaptics (Ubuntu):
assignee: nobody → albertomilone
importance: Undecided → Medium
milestone: none → jaunty-updates
status: New → In Progress
Alberto Milone (albertomilone) wrote :

I found the cause of the problem and I dramatically reduced the problem (we tested this in the OEM team).

Sometimes the reported movement deltas are too big to actually take place in 20 milliseconds or less (no human hand would ever be able to move this fast).

Furthermore, a comparison between the timestamps collected in priv->move_hist and the ones I'm getting for each event shows that something goes wrong and that one or more events are skipped, hence the deltas are wrong (i.e. bigger than they should really be). The next event is wrong too.

Currently, as you can see in the attached patch, I tell the driver to ignore these events and it seems to correct the driver's behaviour. Knowing why some events are skipped would be even better though.

Alberto Milone (albertomilone) wrote :

SRU request:

Here is the debdiff which also includes the patch from bug 365952. Both patches have been tested and the package can be found in the PPA of the X team:
https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates/

Please accept this in jaunty-proposed.

Martin Pitt (pitti) wrote :

This does not match the SRU criteria, is not a regression, not a totally unreasonable behaviour, and is a pretty intrusive patch which is not guaranteed to be regression free on all the hardware out there. Please get this fixed in karmic and upstream instead. Thanks!

Changed in xfree86-driver-synaptics (Ubuntu):
milestone: jaunty-updates → none
John Dong (jdong) wrote :

Ok, you've got report of your first victim here: On both a Macbook Core 2 Duo (touchpad 051c:021a / appletouch) and whatever touchpad the Dell Mini 9 uses, installing 2ubuntu5 from the PPA causes EXTREMELY poor fine-grained control of the touchpad to the point that it is utterly unusable. Long scale movements are exteremely nondeterministic:

Moving slowly (i.e. 0.5cm/sec) across the touchpad produces ZERO movement, swiping across the touchpad rapidly might move the mouse halfway across the screen.

 Maybe the limits are not well tuned or universal?

Martin Pitt (pitti) wrote :

(unsub'ing ubuntu-sru)

I see this 'random jump to somewhere else' problem when using Gimp, under KDE4 (Kubuntu 9.4, Dell 1525n hardware, which is an ALPS/2 synaptics-like touchpad). Most evident when using the 'clone tool'. Dragging across the image with left button down will suddenly jump several hundred pixels up and left.
Dragging in KDE seems fine

Applying 99.3-2ubuntu5 from the PPA has no effect, and the cursor now feels 'sticky' and less responsive even in KDE.

If the user touches the touchpad in two locations, then raises the first finger that touched the pad, the mouse jumps to the location of the second finger as if a full move occurred. This happens on Synaptics touchpads.

To reproduce:
Touch the pad in the upper right and hold
Touch with another finger lower left and hold
Release the finger in the upper right
Mouse jumps to lower left edge of the screen, sometimes selecting text along the way

I have noticed a few symptoms related to the problem. They can be tracked down in ComputeDeltas() in synaptics.c:

1) Sometimes deltas are so big that they couldn't possibly happen in so little time (e.g. in less than 20 milliseconds).

2) A comparison between the timestamp in priv->move_hist and hw->millis shows that something went wrong and that an event was skipped, hence the deltas are wrong (or at least bigger than they should be).

3) Usually when 2) takes place, the next few deltas happen to be inaccurate too.

I have written a patch which is more of a workaround for the touchpads that I own and I believe that, at least 2) could be fixed in a better way. Consider the patch as an additional description.

Let me know if there is something I can do to help or where you would like to see this problem fixed.

I might be worth checking the finger value too, i.e. if the fingers down go
from 2 to 1, then a jump to another position should possibly be ignored.

Please attach the patch to this bugreport, I'd be interested to see it.

Changed in xorg-driver-synaptics:
status: Unknown → Confirmed

Created an attachment (id=25641)
Jumpy cursor patch

Sorry, something went wrong when I tried to attach the patch.

The finger value was the 1st thing I checked but it didn't seem to solve the problems that I was experiencing.

William Grant (wgrant) wrote :

I dropped the patch from my PPA uploads, because I was able to move my finger fast enough to trigger it.

I just tried this patch and it makes the touchpad quite unpredictable. Moving fast towards a point on the screen (a common thing if you want to close a window) makes the touchpad quite edgy with some movements swallowed, etc.

We can't merge this patch as it is. Can you take the finger value into account in the calculations? i.e. if the previous finger value was 2 and is now 1 and there was a huge movement then smoothen it out?

(In reply to comment #4)
> I just tried this patch and it makes the touchpad quite unpredictable. Moving
> fast towards a point on the screen (a common thing if you want to close a
> window) makes the touchpad quite edgy with some movements swallowed, etc.
>
> We can't merge this patch as it is. Can you take the finger value into account
> in the calculations? i.e. if the previous finger value was 2 and is now 1 and
> there was a huge movement then smoothen it out?
>

Sure, I can do that again but it wouldn't work if an event was skipped and we would end up smoothening out the wrong movements.

I'll see what I can do.

Bryce Harrington (bryce) on 2009-07-01
affects: xfree86-driver-synaptics (Ubuntu) → xserver-xorg-input-synaptics (Ubuntu)
Bryce Harrington (bryce) wrote :

Is this still an issue with xserver-xorg-input-synaptics 1.1.2-1ubuntu1 in karmic?

Changed in xserver-xorg-input-synaptics (Ubuntu):
status: In Progress → Incomplete

As this is currently only happening on the touchpads of the newer Minis, would it be acceptable to just detect the model of such touchpads and apply this as a quirk for them?

I have a T61 and it's happening for me too, so this doesn't just affect the Dell minis.

(In reply to comment #7)
> I have a T61 and it's happening for me too, so this doesn't just affect the
> Dell minis.
>

Right, but the reason why the cursor jumps and the solution to the problem may vary according to models.

For example, let's consider the solution which involves smoothening movements when the previous finger value was 2 and is then 1:

1) The Synaptics touchpad in the Dell Mini 10V doesn't detect multiple fingers and two-fingers emulation doesn't work well. If I want that touchpad to detect 2 fingers (through emulation) I can set the relevant properties manually but then my thumb (or using my index with a slightly bigger pressure) is treated as if it were two fingers. And I can't use this solution because there's no clear way to distinguish between 2 fingers and 1 finger.

2) The Synaptics touchpad in my Fujitsu-Siemens detects multiple fingers (natively) and this solution reduces the issue.

3) The Elantech in my Eee 901 Go doesn't report finger pressure but emulation works well and so on.

Furthermore different values assigned to the "threshold" variable (in my patch) can improve or worsen the situation according to the model.

For this reason I was wondering if quirks could be added for different touchpads (when no general solution can be found).

What do you think?

(In reply to comment #8)
> (In reply to comment #7)
> > I have a T61 and it's happening for me too, so this doesn't just affect the
> > Dell minis.
> >
>
[...]
> For this reason I was wondering if quirks could be added for different
> touchpads (when no general solution can be found).
>
> What do you think?
>

I recognize this problem from some time ago. Have you tried applying the ubuntu patches to see if the problem goes away? (apt-get source xserver-xorg-input-synaptics, then look in debian/patches.) There might even be additional patches available at ubuntuforums for this. I am particularly thinking of the patches that disable movement when more than one finger is or recently was in contact with the touchpad.

Created an attachment (id=27760)
Quirk - First draft

I was thinking of something like the attached patch.

NOTE: this quirk is just for Synaptics touchpads and therefore it's applied only if priv->model == MODEL_SYNAPTICS.

If the touchpad can detect multi-finger events then, as Peter suggested, we smoothen out movements after the user raises the second finger from the touchpad. This works well with the Synaptics touchpad in my Fujitsu laptop.

If the touchpad can't detect multi-finger events (e.g. the Dell Mini 10v, the HP Mini, etc.) we smoothen movement events which are (usually) too big take place in so little time. I know that this is not perfect but, as reported by our customers, it's still a big improvement. Furthermore I'm not sure how accurate we can be with this kind of touchpads. Better ideas are always welcome though.

What do you think?

Bryce - I tried out the karmic driver on my Dell Mini 10v and experienced the jumpy trackpad problem described in this bug. The package in the PPA fixes the problem for me.

(In reply to comment #10)
> Created an attachment (id=27760) [details]
> Quirk - First draft
>
> I was thinking of something like the attached patch.
>
> NOTE: this quirk is just for Synaptics touchpads and therefore it's applied
> only if priv->model == MODEL_SYNAPTICS.

fwiw, my synaptics doesn't do multi-finger, so MODEL_SYNAPTICS is not a good quirk selector. priv->has_double and priv->has_triple are set if the touchpad has multi-finger capabilities. This is regardless of the model.

I find the patch quite hard to review, indentation has a certain randomized component to it. the second half (the non-multifinger part) is the one I tested on my non-multifinger pad and it basically made the touchpad unusable for any larger movements. So this part definitely needs fine-tuning.

why is threshold a double? threshold could be based on the pad dimensions too since a movement of 90 on an ALPS is significantly more than on a synaptics pad.

rather than the wasTimeSkipped approach it'd be better to just dump the old values back into the history so dx/dy is automatically 0 on the next run.

(for a final version of that patch, the xf86Msg must disappear too, it'd spam the logs)

> If the touchpad can detect multi-finger events then, as Peter suggested, we
> smoothen out movements after the user raises the second finger from the
> touchpad. This works well with the Synaptics touchpad in my Fujitsu laptop.

I cannot test this. Henrik, any comments?

> If the touchpad can't detect multi-finger events (e.g. the Dell Mini 10v, the
> HP Mini, etc.) we smoothen movement events which are (usually) too big take
> place in so little time. I know that this is not perfect but, as reported by
> our customers, it's still a big improvement. Furthermore I'm not sure how
> accurate we can be with this kind of touchpads. Better ideas are always welcome
> though.

is it possible to make conditional on two-finger emulation in this case. i.e. only smooth if two-finger emu was triggered?

(In reply to comment #11)
> fwiw, my synaptics doesn't do multi-finger, so MODEL_SYNAPTICS is not a good
> quirk selector. priv->has_double and priv->has_triple are set if the touchpad
> has multi-finger capabilities. This is regardless of the model.
>
This is why I did "if (priv->has_double)". Furthermore I don't own ALPS touchpad.

> I find the patch quite hard to review, indentation has a certain randomized
> component to it. the second half (the non-multifinger part) is the one I tested
Yes, I've just noticed that and I'll fix it.

> why is threshold a double? threshold could be based on the pad dimensions too
> since a movement of 90 on an ALPS is significantly more than on a synaptics
> pad.
Good point. Do you refer to priv->minx (etc.) or is there some variable with the physical dimension of the pad?

>
> rather than the wasTimeSkipped approach it'd be better to just dump the old
> values back into the history so dx/dy is automatically 0 on the next run.
>
Ok.

> (for a final version of that patch, the xf86Msg must disappear too, it'd spam
> the logs)
>
Yes, of course. I forgot to remove that.

> is it possible to make conditional on two-finger emulation in this case. i.e.
> only smooth if two-finger emu was triggered?
>
Yes but two-finger emulation doesn't really work well on the Dell Mini 10v therefore it never gets triggered.

(In reply to comment #9)
> I recognize this problem from some time ago. Have you tried applying the ubuntu
> patches to see if the problem goes away? (apt-get source
> xserver-xorg-input-synaptics, then look in debian/patches.) There might even be
> additional patches available at ubuntuforums for this. I am particularly
> thinking of the patches that disable movement when more than one finger is or
> recently was in contact with the touchpad.
>

I wrote the patches in Ubuntu (I'm a Canonical employee) but if you have links to additional patches I would be glad to have a look at them.

Created an attachment (id=27846)
Quirk - Second draft

This patch has the following changes:
1) threshold is an int;
2) the driver now appends skipped events to priv->move_hist;
3) I added priv->model_version so that we can affect as few touchpads as possible. Now the driver tests priv->model, priv->has_double and priv->model_version before the quirk is applied.

NOTE: this patch should be tested with kernel 2.6.29 or higher, otherwise priv->has_double is always reported = 1 instead of its real value.

Any comments?

Peter Silva (peter-bsqt) wrote :

PPA fix confirmed on another Mini10v. it works for me.

Created an attachment (id=27915)
Quirk - Third draft

As regards appending skipped events to priv->move_hist, it makes the cursor jump even when only 1 finger is on the touchpad which is not ideal.

I went back to the was_time_skipped approach. The rest of the patch is the same as before.

nh2 (nh2) wrote :

0.99.3-2ubuntu5 (it is in the X Updates PPA and Karmic, right?) causes the same problems as stated in #4 on a Samsung NC10 and a Dell Latitude 2100. Both touchpads become almost unusable as when moving the finger faster than snail speed, the cursor just stops moving and continues only in small jumps, as if it had hung up somewhere.

A note: That two-finger-hopping is what I would have expected to happen - most notebooks I've used running Windows Synaptic drivers do behave exactly like this. I never knew it was a bug ;-)

If there is a patch to make the pad working again, I'll be glad to test it.

Alberto Milone (albertomilone) wrote :

The latest version in Karmic (1.1.2-1ubuntu2) should fix this. I developed and tested my patch on my Mini10v.

nh2 (nh2) wrote :

For me, 1.1.2-1ubuntu2 in Karmic is broken with just those symptoms on both netbooks. If I move the finger fast, the mouse is almost not moving.

Alberto Milone (albertomilone) wrote :

@nh2

Please follow these steps so that I can see what's happening:

1. Enable the "universe" repository and refresh your packages list.

2. Download and install the deb package of "synaptics-report" (which works on hardy, jaunty and karmic) from this PPA: https://launchpad.net/~albertomilone/+archive/ppa

3. Press CTRL-ALT-F1 to go to the 1st terminal (you'll see only the command line) and log in.

4. Type the following command:

sudo synaptics-report

and follow the instructions which the program will give you.

5. Press ALT-F7 to go back to your desktop environment

6. Look for the synaptics_report.log file in the same directory in which you executed the synaptics-report command (usually your home directory) and attach the file.

nh2 (nh2) wrote :

OK, here you are. I first moved both fingers slowly, then in the speed which triggers the problems, then slowly again.

Alberto Milone (albertomilone) wrote :

I'll change my patch so that my changes affect only specific netbooks such as the Dell Mini 10v (i.e. I'll make the quirk more specific).

Alberto Milone (albertomilone) wrote :

Ok, let's discuss this in bug 405943 which is more about the regression that the patch caused.

I just compared the first version of the patch "Jumpy cursor patch" with the current third version. I tested the first version a while ago on my touchpad which does _NOT_ have multifinger capabilities. I tested this one too.

My comments were that this makes the touchpad unusable as it is quite easy to trigger the threshold when moving fast. Your solution was to special case it for some models and ignore the problem for all others. This is _not_ a solution.

IIRC, dell have alps touchpads with dimensions of 1024. So calculate the threshold based on that and then we can try if the same calculation is valid for synaptics touchpads.

Also, can you remind me again why we need to fix a behaviour for a functionality that the hardware doesn't support? i.e. why we need to behave properly for multi-finger touches if the touchpad is a single-finger pad? I think we discussed that on IRC once but I forgot.

Having just trawled the launchpad reports I see the following picture:
- you filed a bugreport in launchpad about the behaviour described here.
- you applied a patch in ubuntu
- this caused a regression with other touchpads
  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/405943
  which, incidentally is the same issue I described in comment 4.
- you fixed this regression by making special-casing your touchpad so that those users that reported the regression don't see the effect of the patch anymore.

Can you please point to a user (other than you) who has been affected by this behaviour and who confirms that the patch fixes it?

Because, quite frankly, right now I'm not particularly inclined to add special-cases and half-broken patches to the driver to fix something that doesn't seem to affect a lot of users just so we can not support something that isn't supported by the hardware anyway...

(In reply to comment #16)
> IIRC, dell have alps touchpads with dimensions of 1024.

don't know why I thought that, they have synaptics pads.

<email address hidden> wrote:
> http://bugs.freedesktop.org/show_bug.cgi?id=21614
>
>
>
>
>
> --- Comment #16 from Peter Hutterer <email address hidden> 2009-08-19 17:38:25 PST ---
> I just compared the first version of the patch "Jumpy cursor patch" with the
> current third version. I tested the first version a while ago on my touchpad
> which does _NOT_ have multifinger capabilities. I tested this one too.
>
> My comments were that this makes the touchpad unusable as it is quite easy to
> trigger the threshold when moving fast. Your solution was to special case it
> for some models and ignore the problem for all others. This is _not_ a
> solution.
>
> IIRC, dell have alps touchpads with dimensions of 1024. So calculate the
> threshold based on that and then we can try if the same calculation is valid
> for synaptics touchpads.
>
> Also, can you remind me again why we need to fix a behaviour for a
> functionality that the hardware doesn't support? i.e. why we need to behave
> properly for multi-finger touches if the touchpad is a single-finger pad? I
> think we discussed that on IRC once but I forgot.
>
> Having just trawled the launchpad reports I see the following picture:
> - you filed a bugreport in launchpad about the behaviour described here.
> - you applied a patch in ubuntu
> - this caused a regression with other touchpads
>
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/405943
> which, incidentally is the same issue I described in comment 4.
> - you fixed this regression by making special-casing your touchpad so that
> those users that reported the regression don't see the effect of the patch
> anymore.
>
> Can you please point to a user (other than you) who has been affected by this
> behaviour and who confirms that the patch fixes it?
>
> Because, quite frankly, right now I'm not particularly inclined to add
> special-cases and half-broken patches to the driver to fix something that
> doesn't seem to affect a lot of users just so we can not support something that
> isn't supported by the hardware anyway...
>
>

I concur. Temporarily moving from a multi-touch device to a single-touch
device one is bound to notice that they don't behave the same. Using one
finger to point and click is the only supported gesture on single-touch
devices.

Download full text (3.9 KiB)

(In reply to comment #16)
> I just compared the first version of the patch "Jumpy cursor patch" with the
> current third version. I tested the first version a while ago on my touchpad
> which does _NOT_ have multifinger capabilities. I tested this one too.
>
> My comments were that this makes the touchpad unusable as it is quite easy to
> trigger the threshold when moving fast. Your solution was to special case it
> for some models and ignore the problem for all others. This is _not_ a
> solution.

Right, it's a workaround (after all it's a hardware problem). And it has to be very specific to the touchpad model (i.e. to its real dimensions and resolution).

>
> IIRC, dell have alps touchpads with dimensions of 1024. So calculate the
> threshold based on that and then we can try if the same calculation is valid
> for synaptics touchpads.

I have a few netbooks whose touchpads report the same dimensions but have different sizes in real life. This is why, in my opinion, we cannot rely on the reported dimensions and different thresholds have to be set.

>
> Also, can you remind me again why we need to fix a behaviour for a
> functionality that the hardware doesn't support? i.e. why we need to behave
> properly for multi-finger touches if the touchpad is a single-finger pad? I
> think we discussed that on IRC once but I forgot.

I'm not saying that we should support multi-finger touches but if users (and in my case, customers) complain about the cursor being horribly jumpy (and this is not only a problem of the Dell Mini10v) when they accidentally put more than one finger on their touchpad, I think it's worth doing something to make the problem at least less annoying.

>
> Having just trawled the launchpad reports I see the following picture:
> - you filed a bugreport in launchpad about the behaviour described here.
> - you applied a patch in ubuntu
> - this caused a regression with other touchpads
>
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/405943
> which, incidentally is the same issue I described in comment 4.
> - you fixed this regression by making special-casing your touchpad so that
> those users that reported the regression don't see the effect of the patch
> anymore.
>
> Can you please point to a user (other than you) who has been affected by this
> behaviour and who confirms that the patch fixes it?

Sure:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/402863

and:
https://bugs.edge.launchpad.net/ubuntu/+bug/395515

In the second case the one who reported the bug (a colleague of mine) is using my patch (even though he didn't reply in the bug report).

Not to mention the feedback that I received from Dell and other customers, which is why I wanted to fix this upstream.

>
> Because, quite frankly, right now I'm not particularly inclined to add
> special-cases and half-broken patches to the driver to fix something that
> doesn't seem to affect a lot of users just so we can not support something that
> isn't supported by the hardware anyway...
>

I think a final solution (or workaround) would be, as discussed on IRC, a property which allows users to set the threshold...

Read more...

(In reply to comment #19)
> This would be necessary because the kernel doesn't expose enough information
> (and no, ID_VENDOR, ID_PRODUCT and ID_VERSION are not specific enough) to
> identify a specific touchpad model therefore we have to rely on the laptop
> model instead.

the kernel (2.6.31) exports the resolution as well. Are you able to calculate the threshold based on that? That said, as soon as we have that threshold anywhere we kinda need to expose it as an option anyway. but a correct auto-calculation is needed nonetheless.

> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/402863
> https://bugs.edge.launchpad.net/ubuntu/+bug/395515

both bugs describe the issue where the users clicks a button while using a finger. this is what the Synaptics Area property is already for, if this area doesn't work in this use-case then that's the bit that needs fixing.
can you please test this with the area property set to the correct values, the second finger should not have any effect whatsoever if the area is active.

(In reply to comment #20)
> the kernel (2.6.31) exports the resolution as well. Are you able to calculate
> the threshold based on that? That said, as soon as we have that threshold
> anywhere we kinda need to expose it as an option anyway. but a correct
> auto-calculation is needed nonetheless.
>

I'm using kernel 2.6.31 but the resolution is still incorrectly reported as 1x1. I'll look into this problem and see if the resolution can help with this bug.

> > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/402863
> > https://bugs.edge.launchpad.net/ubuntu/+bug/395515
>
> both bugs describe the issue where the users clicks a button while using a
> finger. this is what the Synaptics Area property is already for, if this area
> doesn't work in this use-case then that's the bit that needs fixing.
> can you please test this with the area property set to the correct values, the
> second finger should not have any effect whatsoever if the area is active.
>

In those cases the Synaptics Area was not set but the property works well when used.

I have noticed that the reports which are more specific to the problem we're dealing with are private reports from our customers. Only members of Canonical's OEM team have access to these reports. I can give you the description of their problems (stripped of private information) if you think it can help.

For example the first two paragraphs of the description that I put in this bug report on freedesktop.org were taken from one of our private reports.

(In reply to comment #21)
> (In reply to comment #20)
> I'm using kernel 2.6.31 but the resolution is still incorrectly reported as
> 1x1. I'll look into this problem and see if the resolution can help with this
> bug.

in the driver or in xinput? there's about 5 levels where this can be a bug, so please make sure the driver has the right information.

> I have noticed that the reports which are more specific to the problem we're
> dealing with are private reports from our customers. Only members of
> Canonical's OEM team have access to these reports. I can give you the
> description of their problems (stripped of private information) if you think it
> can help.
>
> For example the first two paragraphs of the description that I put in this bug
> report on freedesktop.org were taken from one of our private reports.

I can understand why two fingers would be used with the special button area. Why else would you use two fingers on a single-touch touchpad?
Looking at the values my touchpad produces here, the ranges that I can trigger with by using two fingers and lifting one are about the same of those when moving fast from one point on the screen to another one.

From an UI point of view, this is quite important: touching the touchpad with two fingers and having the cursor jump is a predictable response that can be avoided by using a single finger only. Having a threshold that cuts off certain movements can interfere with normal usage of the touchpad in a non-deterministic manner.

(In reply to comment #22)
> I can understand why two fingers would be used with the special button area.
> Why else would you use two fingers on a single-touch touchpad?
> Looking at the values my touchpad produces here, the ranges that I can trigger
> with by using two fingers and lifting one are about the same of those when
> moving fast from one point on the screen to another one.
>
> From an UI point of view, this is quite important: touching the touchpad with
> two fingers and having the cursor jump is a predictable response that can be
> avoided by using a single finger only. Having a threshold that cuts off certain
> movements can interfere with normal usage of the touchpad in a
> non-deterministic manner.
>

Users can (and do) accidentally put more than one finger on the touchpad, not only in the use case of the Synaptics Area. For example, if you use your index to move the cursor, it can happen that the middle finger (or another finger) accidentally touches the touchpad surface. On the Dell Mini10v and on some other netbooks when this happens the cursor jumps to the other side of the screen which is really not what I would call "predictable behaviour".

Of course on other models this problem is much less noticeable as in your case or on some other netbooks that I own. For this reason I think that we should adopt a case by case approach and apply the threshold only when the problem is unbearable.

I agree with you that cutting off movements is not ideal but in some cases it can really make a difference, which is why I'm more inclined to develop this as a quirk in the fdi file.

Created an attachment (id=29076)
Quirk - Fourth draft

I have played a bit with touchpad resolutions and I'm still convinced that touchpads with the same resolution and different physical size should act differently, therefore I don't think we should really relay on the resolution.

I have rewritten the patch so that the threshold is a property which we can set through xinput. Customised thresholds for different laptops can now be added to the fdi file. For example I put different values for HP Mini 1000 and Dell Mini10v.

Thanks to this patch users will be able to experiment with different values for the threshold (when the cursor jumps too much), find the one which solves the problem (or which makes it more bearable), get the output of "lshal | grep system.hardware.product" (or some other detail of their laptop) and add a quirk in the fdi file.

Feedback on the patch is welcome.

Bryce Harrington (bryce) wrote :

Hi Alberto, what's the status of this bug report? Should the above patch go in, or wait until we have a regression-free solution?

Alberto Milone (albertomilone) wrote :

Bryce,

A more advanced version of my patch is now included in Karmic and here's the current status:

1) when the Dell Mini 10v is detected it will work well out of the box, thanks to a quirk in the fdi file which sets the property mentioned in point 2

2) users can set the "Synaptics Jumpy Cursor Threshold" property to a value which works for them (which depends on the touchpad model) using either xinput, synclient or the fdi file.

This approach is definitely regression free as (by default) we rely on quirks for 3 models and preserve normal behaviour on other touchpad models.

tags: added: karmic
Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Incomplete → Fix Released
Michael Terry (mterry) on 2009-10-20
tags: added: oem
Manoj Iyer (manjo) wrote :

jana@Ubuntu:/etc/apt$ dpkg -l | grep input-synaptics
ii xserver-xorg-input-synaptics 1.1.2-1ubuntu7 Synaptics TouchPad driver for X.Org server
jana@Ubuntu:/etc/apt$

I seem to have the latest touchpad driver, after doing an update couple of minutes ago, the mouse on my Mini10V is pretty jumpy. I added alberto's ppa but my xserver package is already the newest version and (seems to have the fix ?) is supposed to have the mouse fix for 10V.

is this a regression of some sort ? synaptic-report is missing from the PPA, so cant attach that output like others have done.

Manoj Iyer (manjo) wrote :

After shutting down and restarting the mouse is not jumpy, people have observed that 1/5 times mouse is jumpy, and the rest of the time it seems to work as desired. But I think this is still a bug that needs to be looked at.

Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Fix Released → Fix Committed
Michael Terry (mterry) on 2009-10-28
tags: added: oem-services
removed: oem
Partha (partha1b) wrote :

I reported this as a bug (#459729 - https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/459729) which has received no response at all. This bug is painfully noticeable with Gimp where you are trying to use a bush to work on a painting/photo/whatever. When you use the brush with the touchpad, it will fly across the screen consistently.

nh2 (nh2) wrote :

@ Pantha:
What hardware do you use?

I have a Sony Vaio VGN-FE139E laptop with a AlpsPS/2 ALPS GlidePoint
touchpad. I am using Ubuntu Karmic 9.10.

Let me know if you need more details.

On Sat, Nov 7, 2009 at 11:10 AM, nh2 <email address hidden> wrote:
> @ Pantha:
> What hardware do you use?
>
> --
> Mouse cursor jumps when two fingers are used
> https://bugs.launchpad.net/bugs/365943
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in XOrg-Driver-Synaptics - synaptics driver for XOrg: Confirmed
> Status in “xserver-xorg-input-synaptics” package in Ubuntu: Fix Committed
>
> Bug description:
> Binary package hint: xfree86-driver-synaptics
>
> If the user touches the touchpad in two locations, then raises the first finger that touched the pad, the mouse jumps to the location of the second finger as if a full move occurred. This happens on Synaptics touchpads.
>
> To reproduce:
> Touch the pad in the upper right and hold
> Touch with another finger lower left and hold
> Release the finger in the upper right
> Mouse jumps to lower left edge of the screen, sometimes selecting text along the way
>

nh2 (nh2) wrote :

@ Partha:
Sorry, I misspelled your name in #23.
I'm not sure the bug you reported is this one. Do you use two fingers or does the pointer fly away using only one finger?

Partha (partha1b) wrote :

nh2,

No problems! :)

Yes, I think the bug is the same. I had not noticed the connection
with the usage of two fingers. If you are using any brush (or eraser,
etc.) in Gimp, you are holding down the left button and using another
finger to paint with the brush. Then, bang it flies across the screen
leaving a long streak across the picture. Luckily we have cntrl-Z, but
it gets old pretty fast.

Thanks,
Partha

On Sun, Nov 8, 2009 at 7:44 AM, nh2 <email address hidden> wrote:
> @ Partha:
> Sorry, I misspelled your name in #23.
> I'm not sure the bug you reported is this one. Do you use two fingers or does the pointer fly away using only one finger?
>
> --
> Mouse cursor jumps when two fingers are used
> https://bugs.launchpad.net/bugs/365943
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in XOrg-Driver-Synaptics - synaptics driver for XOrg: Confirmed
> Status in “xserver-xorg-input-synaptics” package in Ubuntu: Fix Committed
>
> Bug description:
> Binary package hint: xfree86-driver-synaptics
>
> If the user touches the touchpad in two locations, then raises the first finger that touched the pad, the mouse jumps to the location of the second finger as if a full move occurred. This happens on Synaptics touchpads.
>
> To reproduce:
> Touch the pad in the upper right and hold
> Touch with another finger lower left and hold
> Release the finger in the upper right
> Mouse jumps to lower left edge of the screen, sometimes selecting text along the way
>

nh2 (nh2) wrote :

But this means your problem also occurs when only one finger is on the touchpad surface, right? This one is about "if the user touches the touchpad in two locations".

Partha (partha1b) wrote :

Well, I have not used the brush with one finger. However, you are
right, I am not touching the touchpad in 2 locations.

On Sun, Nov 8, 2009 at 8:21 AM, nh2 <email address hidden> wrote:
> But this means your problem also occurs when only one finger is on the
> touchpad surface, right? This one is about "if the user touches the
> touchpad in two locations".
>
> --
> Mouse cursor jumps when two fingers are used
> https://bugs.launchpad.net/bugs/365943
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in XOrg-Driver-Synaptics - synaptics driver for XOrg: Confirmed
> Status in “xserver-xorg-input-synaptics” package in Ubuntu: Fix Committed
>
> Bug description:
> Binary package hint: xfree86-driver-synaptics
>
> If the user touches the touchpad in two locations, then raises the first finger that touched the pad, the mouse jumps to the location of the second finger as if a full move occurred. This happens on Synaptics touchpads.
>
> To reproduce:
> Touch the pad in the upper right and hold
> Touch with another finger lower left and hold
> Release the finger in the upper right
> Mouse jumps to lower left edge of the screen, sometimes selecting text along the way
>

jiltsovs (jiltsovs) wrote :

Problem still present in Ubuntu 9.10 on my Samsung x118 (Synaptics touchpad).
But in 1 of 5 system boots two-finger scrolling works fine without cursor jumping.
In 4 of 5 cases cursor starts randomly jump on screen when I touch touchpad with two fingers.
I try to set synclient JumpyCursorThreshold=100
but it only decrease frequency of cursor trembling.
Two-finger scrolling doesn't work in that case.

jiltsovs (jiltsovs) on 2010-01-01
Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Fix Committed → Fix Released
status: Fix Released → Fix Committed
jiltsovs (jiltsovs) on 2010-01-01
Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Fix Committed → Incomplete
Bryce Harrington (bryce) wrote :

Restoring to fix released... From the last few comments it sounds like people were experiencing a problem using a different means to reproduce. Perhaps those issues are now resolved since there has been no further discussion. If not, please file new bug reports.

Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Incomplete → Fix Released

We are seeing a similar problem in Lucid. It appears on multi-touch pads when they aren't reporting as multi-touch. Same symptoms. Jumpy cursor.

madmed (medbelh) wrote :

I have the same problem in hp compaq 610 and using lucid. when I put two fingers on the touchpad the mouse goes crazy :-) this is very annoying. is there any ppa to test a diffrent driver.

madmed (medbelh) wrote :

My problem is gone after today updates. (lucid)

Fixed in 10.4 for me

I have this same problem running lucid on an HP Pavilion. Updates haven't affected the issue for me.

tags: added: lucid

For instance please note that this bug also affects Ubuntu Lucid Lync 10.04 and is reported in launchpad under https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/581659

Files that included are xev output, xorg.0.log file. Another closely related issue reported is the cursor going crazy(instead of being jumpy when reboot from windows) while when booting directly into ubuntu the cursor shows jumpy behaviour as described in this bug report.inspite

Gursimran singh (simar) wrote :

The problem persists in sony vaio vpcCW16fg having synaptics touchpad

Gursimran singh (simar) wrote :

Please refer to bug #581659. It contains some valuable information that confirms the present bug. However as this bug focusses more on resolving and contain some useful patches I have marked them as duplicate.. If anybody thinks that the bug is not a duplicate of this bug please comment in the that bug

https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/581659

Gursimran singh (simar) wrote :

@Bryce Harrington

You have changed the status of this bug as FixReleased. Is it really the case beacuse still the bug persists even in Lucid. This bug has been confirmed in the bug report I have linked above and also in freedesktop the bug status is confirmed and is being worked out ...

Stephen Sandlin (sandlst) wrote :

Strangely enough, I discovered today if I suspend and then resume my computer, the problem fixes itself....at least until I restart.

John Macdonald (jxtreme42) wrote :

sandlst, you're completely right. The problem disappears if you suspend and resume. That's interesting.

As of this git commit, there is code to work around cursor jump on multi-touch transitions for majority cases:

http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=a6ca4d2523904b7ce49edc29ba408979bdf0d45e

This works for both hardware that can report number of fingers and also for cases where it must be emulated from finger width.

As of this next git commit, the default behavior is to enable 2-finger emulation. So effectively, the above patch is working by default for all users.

http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=ffa6dc2809734a6aaa690e9133d6761480603a68

Based on that, I think the intent of this bug report is addressed and you can consider closing it.

Outstanding issue: On my hardware, I must rely on emulation. If I touch opposite extremes of touchpads with two fingers then hardware gets confused and never reports a finger width big enough to trigger 2-finger logic to debounce cursor jumps. But this is an extreme corner case (I don't see it with typical usage) and may be unique to emulation-based hardware only. I've not be able to reproduce jump as long as 1 finger is fully on touchpad.

For this corner case, it may still be useful to add a check in code to see when current X/Y value is at extreme edge of touchpad and if so do some additional checks to try to guess when its because of a corner case (for example when previous X/Y were on opposite extreme of touchpad).

SolidSlash (solidslash) wrote :

It is still present in Maverick. I also wonder why do I have a greyed-out two-finger scroll option in Mouse configuration app? All the gestures (two-finger scroll, three-finger swipe to back/forward in firefox) work wonderful in Windows, what's wrong with it in Ubuntu?

Changed in xorg-driver-synaptics:
importance: Unknown → Medium
Cristian Bravo (the-mad-one-) wrote :

Exactly the same happens to me in a Samsung R480 notebook, with a Synaptics touchpad. The multitouch capabilities are present, because in windows 7 (dual boot) works fine.

Notable things:

1.- The problem does solve when running one finger flat, as was mentioned.
2.- Multitouch capabilities do not work by default, I have to run an (attached) script at startup in order to make multitouch work. I also have them greyed out in mouse options.
3.- The problem appears at random, at times it starts ok and the touchpad works and sometimes it presents the bug.
4.- The problem disappears when resuming.

Hope this help. My ubuntu version is Lucid.

Matteo Rossi (teo-red90) wrote :

Cristian your script doesn't work with my touchpad (Synaptics v7.2) on Maverick. The problem hasn't been solved on my laptop

Federico Bett (gfbett) wrote :

Same problem here. Dell Studio Notebook with a Synaptics touchpad. Moultitouch works perfectly on windows, but in ubuntu (10.10) it jumps randomly when two fingers are used.
Also the problem dissapears if I suspend/resume (but multitouch is still not working). Ah, and the script doesn't work either.

Regards

Markus K. (ehmkey) wrote :

I've the same problem like #71

Dell XPS 15 with Synaptic touchpad

Gursimran singh (simar) wrote :

Hi there,

It has been seen that the this jump problem persist in touchpads that has built in multitouch support(usually newer synaptics touchpads). These touchpads had not been supported for multitouch in linux till now, however using some recent work done by some pros, a experimental version of the multitouch support(using newer protocol) has been released. Please try the dkms package in bug #308191 and unsubscribe here, if the problem disappears because it means the problem was due to wrong kernel driver so the more appropriate solution of the problem should be at the kernel level rather in xserver-xorg-input-synaptics.

This bug and the patches provided here would still cover many touchpads that does not support multitouch capabilities.

Cristian Bravo (the-mad-one-) wrote :

Hi Gursimran!

I checked the package but it seems to be only for Maverick (at least the PPA is...). Do you know if it works on Lucid as well?

Thanks! :D

Beeej (bj-esmailbegui) wrote :

I have a feeling this is related. I have an HP G72 17 inch laptop with Ubuntu 10.10 installed. When put two fingers on the touchpad, the cursor jumps around like a cheerleader on crack. Right now that's all I can say. If there is any testing I can do please let me know.

Created attachment 40902
Add JumpyCursorThreshold option patch v5

For those touchpads that don't support multi-finger or sending correct finger width, the jumpy cursor problem is still there. One notable example is the ClickPad found on Lenovo S10-3t whose ClickPad suffers from this jumpy cursor problem very severely, because its buttons also have sensible surface thus every time you click a button without lifting another finger from the pad, such as when trying to drag a window or select text, the cursor jumps, and renders the whole touchpad nigh unusable.

(if you are wondering why Synaptics driver doesn't enable ClickPad mode and limit the touch area thus ignore ABS sent from button area, it's because those ClickPads send out BTN_LEFT and BTN_RIGHT just as normal touchpads so they don't trigger the ClickPad mode, which is designed for ClickPads that never send BTN_RIGHT)

Therefore Alberto Milone's JumpyCursorThreshold option patch is still needed, which is the best solution I've seen so far. I've attached the new patch I ported to head. I've tested it in MeeGo and it works very well (with Threshold set to 250).

Changed in xorg-driver-synaptics:
importance: Medium → Unknown
status: Confirmed → In Progress
Changed in xorg-driver-synaptics:
importance: Unknown → Medium

Still without final solution? I.e. a year of doing nothing in this concern?

Thomas, according to two comments up, it looks like only a small corner case is left.

Also, Yan, you should bring up your patch for discussion on xorg-devel.

I believe this patch finally fixed this issue:

commit c546779b32d8be23475b3b062e3ebc9235365c0d
Author: Chase Douglas <email address hidden>
Date: Thu Feb 9 16:56:29 2012 -0800

    Ignore motion during touch count changes on semi-mt devices

Changed in xorg-driver-synaptics:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.