[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
aaron at agoragames.com
Thu Nov 29 04:31:59 PST 2012
Peter,
Thank you. This is all new to me and I appreciate the guidance. I've not
committed anything new since my last commit where I bypassed the click
event entirely in favor of a pressure threshold. That's worked better than
before, but double clicks seem problematic. I'll only bother submitting a
patch if I feel like I've made good progress, for now I'm hacking at it and
pushing to github for visibility should anyone be interested.
cheers
On Thu, Nov 29, 2012 at 1:49 AM, Peter Hutterer <peter.hutterer at who-t.net>wrote:
> On Tue, Nov 13, 2012 at 09:15:05PM -0500, Aaron Westendorf wrote:
> > "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.
>
>
> :: whot at yabbi:~> cat /etc/X11/xorg.conf.d/99-synaptics-dontgrab.conf
> Section "InputClass"
> Identifier "Don't grab synaptics"
> MatchDriver "synaptics"
> Option "GrabEventDevice" "off"
> EndSection
>
> then evtest will work at any time.
>
> > 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
>
> the pull request model is horrible to actually review changes since one has
> to copy/paste hunks out of context, etc. Please do send your patches to the
> list if you have any that are useful.
>
> what will help in this case is if you can get a device recording with evemu
> of such a spurious click event so I get a clearer picture.
>
> Cheers,
> Peter
>
> >
> > -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
> > _______________________________________________
> > xorg-devel at lists.x.org: X.Org development
> > Archives: http://lists.x.org/archives/xorg-devel
> > Info: http://lists.x.org/mailman/listinfo/xorg-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20121129/9090d9d4/attachment-0001.html>
More information about the xorg-devel
mailing list