[PATCH] If using a clickpad, filter out all left-click events where there's no finger on the trackpad or it's a light touch

[Aaron Westendorf]

"Bending" and "flex" are simply the best description I have; the
Series 9 is unibody and flex is practically non-existent. For all I
know, it's a voltage potential as a result of movement of my hand
along any part of the chassis. There is no single way to cause the
kernel to send spurious clicks. Typing and any touching along the palm
rest are capable of causing it, as well as picking it up, changing the
screen angle, etc.

The patch did not fully solve the problem though. Over the weekend I
found that the bug continued to cause trouble as I used the laptop
more, and so I introduced "ClickHigh", similar to "FingerHigh" and
operating solely on clickpads to insist that a button event only be
registered if past a certain pressure (default of 0 uses click event
as-is). This filtered out cases where I was scrolling or moving the
mouse pointer and the kernel sent a click, causing scroll to stop,
text to be highlighted, and so on.  My problems have largely gone away
though I'm still experimenting with it, trying to find the cases where
it does not perform as desired (and there are a few). I have found
that my clicks aren't always registered; I suppose that this is
because the button event is sent before the pressure threshold is
reached but seeing as it's configurable I can't yet say if it's my
implementation or the setting. In order to skip all clicks and use
only pressure to determine a click I'd also need to add a ClickLow
setting. I'm unsure if this is a wise approach.

It's really important to me to see this fixed. I could maintain my own
patches but I can't possibly be the only one to encounter this. The
root bug seems to be in the kernel, I did not notice the problem when
I first installed (K)ubuntu 12.04 and it got progressively worse in
the past several weeks (perhaps lending credence to it being a
grounding problem in the hardware). Working on the kernel though is
outside the scope of what I have resources for at this time.

The loss of the shm functionality makes testing the driver a lot
harder. I can switch VTs and see kernel events, but the shm feature
allowed me to capture output as I used the desktop, and then review
what happened after I observed a bug.

The pull request model of github seems better for this kind of hacking
and I don't want to spam the list with lots of little changes, so
please let me know how best to keep this discussion going.
https://github.com/awestendorf/xf86-input-synaptics/pull/1

-Aaron

On Tue, Nov 13, 2012 at 2:34 PM, Chase Douglas <chase.douglas at ubuntu.com> wrote:
> On Fri, Nov 9, 2012 at 11:43 AM, Aaron Westendorf <aaron at agoragames.com>
> wrote:
>>
>> ---
>>  src/eventcomm.c |   20 +++++++++++++++++++-
>>  1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/eventcomm.c b/src/eventcomm.c
>> index b1d5460..09e8a50 100644
>> --- a/src/eventcomm.c
>> +++ b/src/eventcomm.c
>> @@ -652,7 +652,25 @@ EventReadHwState(InputInfoPtr pInfo,
>>              v = (ev.value ? TRUE : FALSE);
>>              switch (ev.code) {
>>              case BTN_LEFT:
>> -                hw->left = v;
>> +                /**
>> +                 * Filter spurious events from the kernel in cases where
>> +                 * chassis flex causes it to send a button press event.
>> +                 * Ignore clickpad events if nothing was pressed or using
>> +                 * !=1 finger with click pressure. There is still a case
>> +                 * where resting a finger on the pad and a palm press on
>> the
>> +                 * keyboard rest will trigger an event and that will pass
>> +                 * pass through this filter. TBD on best course of action
>> to
>> +                 * filter that out, because we want to recognize press
>> events
>> +                 * to allow mouse movement, but not register as a click.
>> The
>> +                 * old FingerPress option seems like the right choice but
>> +                 * it's been deprecated. Filtering that out could require
>> +                 * complicated heuristics, so for now do a reasonable job
>> +                 * by insisting that the pressure be at least the value
>> +                 * of FingerHigh.
>> +                 */
>> +                if (para->clickpad!=1 || (hw->numFingers==1 && hw->z >=
>> para->finger_high)) {
>> +                  hw->left = v;
>> +                }
>>                  break;
>>              case BTN_RIGHT:
>>                  hw->right = v;
>
>
> It's not 100% clear to me the problem you are facing, but I think I get it.
> I'll try to restate to verify:
>
> You are having issues where a button press is occurring when the user isn't
> actually using the trackpad. You see the issue in your hardware by simply
> bending the machine in a specific way. You hope that by filtering out button
> presses when no "touch" is active will resolve the issue.
>
> If that's all correct, then this patch looks like a good approach. However,
> there is a problem. I own a Dell Mini 1012 netbook with a clickpad. It is
> trivially easy, and occurs often in normal use, to depress the clickpad
> button without a "touch" being seen. In fact, I believe one of my original
> clickpad patches had similar filtering to what you describe, but people
> complained that their button presses weren't working.
>
> My first inclination is to say that we can't always fix hardware defects in
> software. If bending your laptop causes a spurious click, then stop bending
> it :). If you and others feel that this must be fixed, then I think we will
> either need a blacklist of machines that should *not* be filtered (including
> the Dell netbook), or we will need a whitelist of machines that *should* be
> filtered (including your laptop model).
>
> -- Chase