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 <[email protected]>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@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 <[email protected]> > wrote: > > > On Fri, Nov 9, 2012 at 11:43 AM, Aaron Westendorf < > [email protected]> > > > 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 > > _______________________________________________ > > [email protected]: X.Org development > > Archives: http://lists.x.org/archives/xorg-devel > > Info: http://lists.x.org/mailman/listinfo/xorg-devel > > >
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
