[PATCH 0/3] Input: synaptics - multitouch and multifinger support

Takashi Iwai tiwai at suse.de
Fri Oct 8 10:46:27 PDT 2010


At Fri, 08 Oct 2010 13:15:35 -0400,
Chase Douglas wrote:
> 
> On Fri, 2010-10-08 at 18:37 +0200, Takashi Iwai wrote:
> > At Fri,  8 Oct 2010 10:57:57 -0400,
> > Chase Douglas wrote:
> > > 
> > > Tobyn Bertram reverse engineered the multitouch protocol for Synaptics devices.
> > > I've been able to take his work and produce a series of commits to enable MT
> > > and multifinger (MF) support.
> > > 
> > > Unfortunately, there's a tricky issue with some Synaptics touchpads that have
> > > integrated buttons. For example, the left and right buttons on the touchpad of
> > > my Dell Mini 1012 consist of the lower ~20% of the touchpad surface. The
> > > touchpad physically clicks under these areas.
> > > 
> > > The X synaptics input module now has a parameter to disable touches occuring
> > > over the button area, but this solution still doesn't work perfectly. If you
> > > click a button and drag with another finger near the clicking finger, the
> > > touchpad gets confused.
> > > 
> > > Now that we have full MT support, we can try to handle this scenario better.
> > > What I've found to work best is to make touches vanish if they occur over the
> > > button area of the trackpad while any button is held. This works in conjunction
> > > with the X synaptics driver to disable single touch control over the button
> > > area. With full MT support, the touchpad doesn't seem to get confused when a
> > > click and drag occurs with two fingers close to each other, and it enables MT
> > > gestures and MF support across the entire trackpad when no buttons are held.
> > > 
> > > The first question is whether this seems appropriate to others, or if some
> > > other method would work better. Secondarily, should the solution occur in the
> > > kernel, like I have in the third patch of this series, or should it occur in
> > > the X input module? Although we don't have this information today, we may be
> > > able to query the touchpad in the future to know the area of the integrated
> > > buttons. If that were possible, would the recommended location for the hack
> > > change?
> > 
> > Great!  Finally someone found it out!
> > I found this and made a series of patches in 4 months ago.  Since
> > then, Novell legal prohibited me to send the patches to the upstream
> > due to "possible patent infringing".  Now you cracked out.  Yay.
> > 
> > FWIW, my corresponding patch is below.  It really looks similar in the
> > end ;)  I added a kconfig just to be safer.
> > 
> > Regarding the "clickpad" support: in my case, I implemented almost
> > everything about it in xorg driver.  I'm going to submit xorg
> > patches.
> 
> So I'm confused. I was working off of source code posted to:
> 
> https://bugs.launchpad.net/utouch/+bug/633225
> 
> I was under the impression that someone else had reverse engineered the
> protocol and written patches. But the code is exactly the same as what
> you've posted here. If you're the originator of the work, and my patch
> is accepted, I think we'll need your SOB on it. Of course, if your patch
> is accepted then the point is moot :).

Hm, then this was a leak, likely taken from Novell bugzilla or build
service.  The patch was written and published once before I was
prohibited to send to upstream, so basically it was fine to go outside
by itself ;)

> My patch essentially is a rework of yours, incorporating changes that
> allow for the driver to work in single touch and multitouch mode
> simultaneously. As is done in other MT drivers, one touch is picked to
> act as the single touch emulation.
> 
> However, as I sit here using the touchpad and thinking some more, I'm
> not sure how to best handle single touch emulation for synaptics. Single
> touch emulation only really works when touches are tracked. The touches
> from the synaptics driver are swapped whenever one touch moves and the
> other stays stationary. I think I'm noticing some issues with the
> following sequence of events:
> 
> 1. Two touches begin, triggering a DOUBLETAP key event
> 2. X synaptics treats DOUBLETAP as scroll events
> 3. One touch moves up, it's sent as ABS_{X,Y}, scroll performed
> 4. The touch in motion stops
> 5. Other touch moves up, it's now sent as ABS_{X,Y}
> 6. X synaptics scroll behaves poorly because this new touch's X,Y are in
> a different place from the first touch's X,Y. Scrolling seems to snap
> back to original location
> 
> Certainly it's not hard to perform touch tracking when only two touches
> are active. However, Henrik, as the MT input guru, has resisted doing in
> kernel tracking, at least in a hackish, per-driver manner. It's why he
> wrote mtdev in user space, for example. However, unless mtdev is
> extended to support single touch emulation, we're kind of stuck without
> in kernel tracking.

Yeah, there are lots of rooms regarding the handling of multi-touch
touchpad.

I feel that handling the touchpad in the same way as touch-screen
isn't always wise even though they are both multi-touch, since they
are completely different devices; the movement of the former is
relative while the latter takes always the absolute coordinate.

Anyway, I'd love to help improving things once when I'm back to work.


thanks,

Takashi


More information about the xorg-devel mailing list