registry team mailing list archive

[Bug Watch Updater <308191@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 28 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=21614.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2009-05-07T02:38:09+00:00 Alberto Milone wrote:

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.

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/8

------------------------------------------------------------------------
On 2009-05-07T03:42:13+00:00 Peter Hutterer wrote:

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.

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/9

------------------------------------------------------------------------
On 2009-05-08T07:17:26+00:00 Alberto Milone wrote:

Created an attachment (id=25641)
Jumpy cursor patch

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/10

------------------------------------------------------------------------
On 2009-05-08T11:18:00+00:00 Alberto Milone wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/11

------------------------------------------------------------------------
On 2009-05-24T18:17:08+00:00 Peter Hutterer wrote:

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?

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/12

------------------------------------------------------------------------
On 2009-06-06T03:51:56+00:00 Alberto Milone wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/13

------------------------------------------------------------------------
On 2009-07-10T08:32:47+00:00 Mario Limonciello wrote:

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?

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/14

------------------------------------------------------------------------
On 2009-07-11T01:06:25+00:00 Peter Hutterer wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/15

------------------------------------------------------------------------
On 2009-07-11T10:22:41+00:00 Alberto Milone wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/16

------------------------------------------------------------------------
On 2009-07-15T12:00:04+00:00 Henrik Rydberg wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/17

------------------------------------------------------------------------
On 2009-07-16T07:09:11+00:00 Alberto Milone wrote:

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?

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/18

------------------------------------------------------------------------
On 2009-07-16T19:03:03+00:00 Peter Hutterer wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/19

------------------------------------------------------------------------
On 2009-07-17T00:32:04+00:00 Alberto Milone wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/20

------------------------------------------------------------------------
On 2009-07-20T03:43:38+00:00 Alberto Milone wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/21

------------------------------------------------------------------------
On 2009-07-20T07:15:03+00:00 Alberto Milone wrote:

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?

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/22

------------------------------------------------------------------------
On 2009-07-22T06:18:27+00:00 Alberto Milone wrote:

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.

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/24

------------------------------------------------------------------------
On 2009-08-19T17:38:25+00:00 Peter Hutterer wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/25

------------------------------------------------------------------------
On 2009-08-19T18:25:04+00:00 Peter Hutterer wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/26

------------------------------------------------------------------------
On 2009-08-20T00:05:08+00:00 Henrik Rydberg wrote:

bugzilla-daemon@xxxxxxxxxxxxxxx wrote:
> http://bugs.freedesktop.org/show_bug.cgi?id=21614
> 
> 
> 
> 
> 
> --- Comment #16 from Peter Hutterer <peter.hutterer@xxxxxxxxx>  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.

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/27

------------------------------------------------------------------------
On 2009-08-20T00:33:05+00:00 Alberto Milone wrote:

(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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/28

------------------------------------------------------------------------
On 2009-08-20T15:28:25+00:00 Peter Hutterer wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/29

------------------------------------------------------------------------
On 2009-08-20T16:31:22+00:00 Alberto Milone wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/30

------------------------------------------------------------------------
On 2009-08-20T16:57:44+00:00 Peter Hutterer wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/31

------------------------------------------------------------------------
On 2009-08-21T01:19:43+00:00 Alberto Milone wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/32

------------------------------------------------------------------------
On 2009-09-01T07:41:22+00:00 Alberto Milone wrote:

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.

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/33

------------------------------------------------------------------------
On 2010-03-24T16:58:29+00:00 Jim Rorie wrote:

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.

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/73

------------------------------------------------------------------------
On 2010-07-03T12:23:43+00:00 Gursimran singh Mohar wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/88

------------------------------------------------------------------------
On 2010-08-24T11:20:35+00:00 Chris-cnpbagwell wrote:

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

Reply at: https://bugs.launchpad.net/linux/+bug/308191/comments/93


** Changed in: xorg-driver-synaptics
       Status: Unknown => Confirmed

** Changed in: xorg-driver-synaptics
   Importance: Unknown => Medium

-- 
Multitouch support not available for Synaptics touchpads v7.2
https://bugs.launchpad.net/bugs/308191
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for XOrg-Driver-Synaptics.