At Fri, 08 Oct 2010 18:37:22 +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.

BTW, yet another kernel patch is missing; the support of embedded LED.I've posted this once, but it seems forgotten since then. Repostedbelow.

Takashi

---From: Takashi Iwai <tiwai@suse.de>Subject: [PATCH 2/2] input: Add LED support to Synaptics deviceThe new Synaptics devices have an LED on the top-left corner.This patch adds a new LED class device to control it. It's createddynamically upon synaptics device probing.

The LED is controlled via the command 0x0a with parameters 0x88 or 0x10.This seems only on/off control although other value might be accepted.

The detection of the LED isn't clear yet. It should have been the newcapability bits that indicate the presence, but on real machines, itdoesn't fit. So, for the time being, the driver checks the product idin the ext capability bits and assumes that LED exists on the knowndevices.