lkml.org 
[lkml]   [2010]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/3] Input: synaptics - multitouch and multifinger support
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


\
 
 \ /
  Last update: 2010-10-08 19:49    [W:0.170 / U:23.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site