(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