<div class="gmail_quote">On Sat, Dec 18, 2010 at 11:38 AM, Chris Bagwell <span dir="ltr"><<a href="mailto:chris@cnpbagwell.com">chris@cnpbagwell.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Sat, Dec 18, 2010 at 7:17 AM, Yan Li <<a href="http://yan.i.li" target="_blank">yan.i.li</a>@<a href="http://intel.com" target="_blank">intel.com</a>> wrote:<br>
> On Sat, 2010-12-18 at 03:18 +0800, Chris Bagwell wrote:<br>
>> OK, I've re-reviewed patch and I've decided I understand what its<br>
>> trying to do now. Most my original comments still apply but I've<br>
>> added new ones.<br>
>><br>
>> First, I need to confirm intent of patch is this:<br>
>><br>
>> * Create a rectangle defined by {Top|Bottom|Left|Right}Edge that<br>
>> excludes button area in attempt to cause cursor not to move when in<br>
>> that area.<br>
><br>
> This was indeed the intent of Iwai's patch, on which my v4 was based.<br>
> However, based on my recent testing on several different models of<br>
> touchpad, I think that was not a best solution. Because the design goal<br>
> of ClickPad is to remove the physical buttons so that the space used by<br>
> them can be saved, and touchpad can be enlarged on small netbooks with<br>
> very limited surface space. Therefore it was wrong on the software side<br>
> to limit the area a user can touch, because this was against the<br>
> original idea of using a clickable touchpad. With this patch, the<br>
> touchable area was limited to a very small region, not so good a user<br>
> experience.<br>
><br>
> I've tested the official driver from Synaptics in Windows, and it<br>
> doesn't restrict the touchable area, which means the whole pad is<br>
> touchable and clickable. The problem why we chose the current solution<br>
> was actually due to jumpy cursor -- when the user is touching the pad to<br>
> move the course and at the same time use another finger to click the<br>
> lower clickable area, the cursor would jump unexpectedly. The old<br>
> solution used in this patch was to limit the touchable area and ignore<br>
> abs sent from button areas. But since then I have shifted my focus from<br>
> this old solution to fix the jumpy cursor problem instead.<br>
><br>
> I've carefully examined the jumpy cursor problem found in Lenovo S10-3t,<br>
> whose touchpad doesn't support two-finger nor finger-width. Finally I<br>
> found Alberto Milone's patch from bug #21614 is the best solution, and<br>
> I've ported it to latest HEAD:<br>
> <a href="https://bugs.freedesktop.org/attachment.cgi?id=40902" target="_blank">https://bugs.freedesktop.org/attachment.cgi?id=40902</a><br>
><br>
> So I suggest we rework this ClickPad patch, keep only the clicking<br>
> interpretation part and remove the area limit, and try to fix the jumpy<br>
> cursor problem (and I'm using JumpyCursorThreshold patch v5 I linked<br>
> above in MeeGo, so far the feedback is very good).<br>
><br>
<br>
</div></div>Thank for detailed reply. Do you mind helping me understand how<br>
touchpad is being used when jumps occur? Is use case:<br>
<br>
* Move cursor to area you want to click with 1 finger. Pick up 1<br>
finger. Click in button area with 1 finger.<br>
<br>
or<br>
<br>
* Move cursor to area you want to cick with 1 finger. Leave 1 finger<br>
on pad. Click in button area with 2nd finger.<br>
<br></blockquote><div><br></div><div>This is the use case that I prefer, and at least for me, the one causing the most issues. The fact that I can't use it in this way right now drives me nuts. :)</div><div>--</div><div>
Matt </div></div>