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

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.

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!

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.

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 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.

(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.

(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.

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.

(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.

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.

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.

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 touchpadshttps://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...

<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.

(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?

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...

(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.

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.

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.

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.

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.

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.

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.

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
>

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
>

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
>

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.

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.

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

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

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 ...

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).

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?

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.

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.

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.

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.

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).

Lenovo Egde 2-1580, Ubuntu 16.04
I have this problem, so I suppose the fix hasn't made into the standard release yet.
Linux is quite new to me - could someone explain how to go about solving the issue?