Peter,<div> </div><div>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.</div> <div> </div><div> </div><div>cheers</div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Nov 29, 2012 at 1:49 AM, Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">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. </div></div>:: 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. <div class="im"> > 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. > <a href="https://github.com/awestendorf/xf86-input-synaptics/pull/1" target="_blank">https://github.com/awestendorf/xf86-input-synaptics/pull/1</a> </div>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 <div><div class="h5"> > > -Aaron > > On Tue, Nov 13, 2012 at 2:34 PM, Chase Douglas <<a href="mailto:chase.douglas@ubuntu.com">chase.douglas@ubuntu.com</a>> wrote: > > On Fri, Nov 9, 2012 at 11:43 AM, Aaron Westendorf <<a href="mailto:aaron@agoragames.com">aaron@agoragames.com</a>> > > 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 </div></div>> _______________________________________________ > <a href="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</a>: X.Org development > Archives: <a href="http://lists.x.org/archives/xorg-devel" target="_blank">http://lists.x.org/archives/xorg-devel</a> > Info: <a href="http://lists.x.org/mailman/listinfo/xorg-devel" target="_blank">http://lists.x.org/mailman/listinfo/xorg-devel</a> > </blockquote></div> </div>