[PATCH] ClickPad support v4

[Chris Bagwell]

On Sat, Dec 18, 2010 at 7:17 AM, Yan Li <yan.i.li at intel.com> wrote:
> On Sat, 2010-12-18 at 03:18 +0800, Chris Bagwell wrote:
>> OK, I've re-reviewed patch and I've decided I understand what its
>> trying to do now.  Most my original comments still apply but I've
>> added new ones.
>>
>> First, I need to confirm intent of patch is this:
>>
>> * Create a rectangle defined by {Top|Bottom|Left|Right}Edge that
>> excludes button area in attempt to cause cursor not to move when in
>> that area.
>
> This was indeed the intent of Iwai's patch, on which my v4 was based.
> However, based on my recent testing on several different models of
> touchpad, I think that was not a best solution. Because the design goal
> of ClickPad is to remove the physical buttons so that the space used by
> them can be saved, and touchpad can be enlarged on small netbooks with
> very limited surface space. Therefore it was wrong on the software side
> to limit the area a user can touch, because this was against the
> original idea of using a clickable touchpad. With this patch, the
> touchable area was limited to a very small region, not so good a user
> experience.
>
> I've tested the official driver from Synaptics in Windows, and it
> doesn't restrict the touchable area, which means the whole pad is
> touchable and clickable. The problem why we chose the current solution
> was actually due to jumpy cursor -- when the user is touching the pad to
> move the course and at the same time use another finger to click the
> lower clickable area, the cursor would jump unexpectedly. The old
> solution used in this patch was to limit the touchable area and ignore
> abs sent from button areas. But since then I have shifted my focus from
> this old solution to fix the jumpy cursor problem instead.
>
> I've carefully examined the jumpy cursor problem found in Lenovo S10-3t,
> whose touchpad doesn't support two-finger nor finger-width. Finally I
> found Alberto Milone's patch from bug #21614 is the best solution, and
> I've ported it to latest HEAD:
> https://bugs.freedesktop.org/attachment.cgi?id=40902
>
> So I suggest we rework this ClickPad patch, keep only the clicking
> interpretation part and remove the area limit, and try to fix the jumpy
> cursor problem (and I'm using JumpyCursorThreshold patch v5 I linked
> above in MeeGo, so far the feedback is very good).
>

Thank for detailed reply.  Do you mind helping me understand how
touchpad is being used when jumps occur?  Is use case:

* Move cursor to area you want to click with 1 finger.  Pick up 1
finger.  Click in button area with 1 finger.

or

* Move cursor to area you want to cick with 1 finger.  Leave 1 finger
on pad.  Click in button area with 2nd finger.

First case would move cursor a little bit because of how sensitive
touchpads are and lots of X/Y can be sent between time of touch and
button press completed.  But it should not be large jump.  We may need
to add a gesture style delay when touching in button area so we can
tell difference between button press and real movement.

Second case seems more likely to cause a jump but a) synpatics
hardware continues to report 1st finger's X/Y during double touch and
b) we have code to expect a jump just in case during that second touch
based on either doubletap or finger width.  Are you working with
non-synaptics clickpads?

Is there any chance you could reproduce basic sequence when jumps
occur but using evtest and send me the output?

This is one of those problems really buggy me for some reason and I'd
like to help resolve it.

Chris