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.
Created attachment 25641 [details] [review] 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.
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.
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 attachment 27760 [details] [review] 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?
(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 attachment 27846 [details] [review] 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?
Created attachment 27915 [details] [review] 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.
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.
bugzilla-daemon@freedesktop.org wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=21614 > > > > > > --- Comment #16 from Peter Hutterer <peter.hutterer@who-t.net> 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? 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 thresholds so that users can try what works best for them. When they find the right value to assign the threshold we can simply add a quirk to the fdi file such as the following: <match key="system.hardware.product" contains="Inspiron 1011"> <merge key="input.x11_options.JumpyCursorThreshold" type="string">90</merge> and preserve the driver's behaviour on other laptops. 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. In conclusion, if you're willing to adopt this workaround (or have a better one in mind) in the driver then I'll work on it, otherwise, if you think it's a won't fix, just close the report. Thanks
(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 attachment 29076 [details] [review] 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.
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.
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
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).
Created attachment 40902 [details] [review] 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).
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 <chase.douglas@canonical.com> Date: Thu Feb 9 16:56:29 2012 -0800 Ignore motion during touch count changes on semi-mt devices
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.