On 12/15/2010 02:14 PM, Chris Bagwell wrote: > On Wed, Dec 15, 2010 at 11:47 AM, Chase Douglas > <chase.douglas@xxxxxxxxxxxxx> wrote: >> On 12/15/2010 09:21 AM, Henrik Rydberg wrote: >>>> After some testing this is mostly fine, >>> >>> but I have one of those terrible >>>> "integrated buttons" (or whatever we call it) trackpads. When switching >>>> to multitouch mode, the cursor will sometimes jump when I go to push the >>>> button. >>>> >>>> Take the following sequence: >>>> >>>> 1. Touch in top right corner of pad to position cursor >>>> 2. Touch in bottom left corner over button >>>> 3. Press button, but finger moves a little >>>> >>>> Step 3 causes the primary coordinates in the synaptics MT protocol to >>>> flip to the button-pressing touch. This causes a cursor jump. *Many* >>>> times I have gone to press an "Ok" dialog button and found that I >>>> accidentally launched an application from my dock :). >>> >>> >>> I see - the behavior of the primary coordinates seems to vary between models, >>> then. On the other hand, if you point and click with the same finger, one could >>> possibly go around this problem, even though it means less precision. On my MT >>> laptop, I can click at the very edge of the pad without the cursor moving. >> >> Because of the mechanical properties of my particular touchpad, it's >> nearly impossible to click without dragging. My touchpad isn't one of >> the new clickpads where the entire pad hinges. On a clickpad, I would >> hope depress without movement is easy. On my trackpad, the buttons are >> somewhat stiff and flex non-uniformly, causing the unwanted movement. >> >> So, in Ubuntu we mask out the area of the touchpad where the buttons >> are. Any movement in that area is discarded. Thus, the only way to be >> sure of a click is to position with one touch, then lift the touch, then >> click one of the buttons. Annoying :). > > Is this custom code or in upstream (are you talking about > inside_active_area logic?)? I'm not sure why your seeing a jump if > its being discarded. There is a chance that something related to this > discard logic is defeating the other logic that handles jumps caused > during finger transitions. In Ubuntu 10.10 I think we are using an in-house patched hack. It was necessary for an Dell Minis, which was a paid OEM services project, so we needed a fix ASAP at the time. I believe xf86-input-synaptics has an option for this now, so we'll probably transition whenever someone gets a chance to take another look. It may be something that would be handled better by the upstream logic. When I get a chance I'll try the upstream logic instead. >>>> I think we should perform some rudimentary touch tracking to ensure the >>>> same touch is always used for reporting ABS_X/ABS_Y. A simple distance >>>> comparison between the two touches, as I implemented in one of my other >>>> patches, would suffice. >>> >>> >>> One can certainly decide on the "best" coordinates when putting down the second >>> finger, as we tried for elantech. However, after some movement, when the second >>> finger is lifted, chances are you get a jump then instead. >> >> Chris, isn't this filtered out in xf86-input-synaptics based on the >> change in the number of touches? > > Yes, in version 1.30 or newer xf86-input-synaptics anyways. And of > course the *TAP transition needs to come in same sync window as jump > for it to be helpful. It may be able to handle if *TAP comes 1 sync > window before jump but that would be about the limit. Ahh! I'm only running 1.22.2, so maybe I should try out the newer synaptics too. > Mind sending me a evtest log snippet during > touch-then-click-with-2nd-finger (with MT mode enabled)? Seeing those > tends to be better for understanding then words for me. I'm > interested for more then just this specific issue, btw. > > I'm really interested in where the *TAP come (before or after) > relative to cursor jump and how close it was to being filtered out by > xf86-input-synaptics. I'll get this when I get a chance. I'm really crazy backed up with work right now, and holidays are coming up. I'm supposed to be off for the rest of the year, but I doubt that will hold perfectly :). So, if I forget to get you data in the next week or two, feel free to ping me privately. >>>> What do you think? >>> >>> >>> The general approach we have taken for the kernel is to provide a left button >>> for both the macbooks and these clickpads, and in addition provide enough >>> information (read mt data) to solve this problem in userspace. In other words, >>> one should probably see what additions are needed in the common X drivers to >>> make the experience a pleasant one. >> >> I think we're confusing clickpads and my "integrated buttons" trackpad >> (I know we settled on a different name, but I can't remember it now :). >> I believe my issue is purely due to the primary coordinates switching >> back and forth between two touches as I position and click with two fingers. > > I would think they both have same issue... Just yours may have some > extra movement and pressure changes compared to the other. Ok. Thanks, -- Chase -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
