[PATCH] UBUNTU: (pre-stable): input: Support Clickpad devices in ClickZone mode

[Robert Hooker]

On Wed, Dec 15, 2010 at 5:00 PM, Chase Douglas
<chase.douglas at canonical.com> wrote:
> On 12/15/2010 09:06 AM, Tim Gardner wrote:
>> On 12/15/2010 03:44 AM, Henrik Rydberg wrote:
>>> On 12/14/2010 11:06 PM, Robert Hooker wrote:
>>>
>>>> From: Takashi Iwai<tiwai at suse.de>
>>>>
>>>> Add the experimental support of new Synatpics "Clickpad" devices.
>>>>
>>>> This device reports the click as the middle-button, but it doesn't set
>>>> proper capability bits.  Thus the driver needs to check the product-id
>>>> and forces to enable the button detection.
>>>>
>>>> In this patch, the device behaves as "ClickZone" mode, and gives
>>>> compatible events as other normal synaptics devices so that user-space
>>>> app works as is.  In the ClickZone mode, the buttons are emulated as
>>>> clicks in the bottom button zone.  Left and right clicks are judged by
>>>> the touch position.  Clicking the narrow middle point in the button
>>>> zone gives a middle click.
>>>>
>>>> Dragging can be done by keeping the button down and touching the normal
>>>> area again.  Strangely, the sequence to click after touching the area
>>>> doesn't work with this device by unknown reason...
>>>>
>>>> Signed-off-by: Takashi Iwai<tiwai at suse.de>
>>>>
>>>> BugLink: http://bugs.launchpad.net/bugs/516329
>>>>
>>>> Acked-by: Colin King<colin.king at canonical.com>
>>>> Acked-by: Andy Whitcroft<apw at canonical.com>
>>>> Signed-off-by: Chase Douglas<chase.douglas at canonical.com>
>>>> Signed-off-by: Andy Whitcroft<apw at canonical.com>
>>>>
>>>> Fixed clickpad capability checks to only check the 0x0c cap.
>>>>
>>>> Signed-off-by: Robert Hooker<robert.hooker at canonical.com>
>>>> ---
>>>
>>>
>>> Just a heads-up that this will conflict again as we move to 2.6.38.
>>>
>>
>> No worries on that score since Maverick won't get pulled forward anyways.
>>
>> As suggested, I like the revert, then the patch from Takashi Iwai (which
>> should be marked as SAUCE). Its pretty close to what is coded in Linus'
>> repo. (see 5f57d67da87332a9a1ba8fa7a33bf0680e1c76e7)
>
> I have hesitations about this patch. This patch defines left and right
> button zones. I had thought that clickpads *always* had these zones
> marked, but this does not appear to be the case. I played with a Chrome
> Cr-48 laptop with a clickpad, and it does not have any markings on the
> trackpad. So, if this patch is applied and someone installs it on such a
> laptop, they may be confused as to why a click is behaving differently
> depending on where they tap.
>
> This all boils down to usability, imo. I'm not always the best judge of
> these things, and I don't have the hardware to play with. Thus, I'm
> giving a half-ack. I think the code is correct for what it wants to
> accomplish. If others feel this is the best usability route, feel free
> to add my Acked-by tag to the patch. An alternative would be
> cherry-picking the patch from upstream, where a click anywhere is
> interpreted as a left click. I'm also not sure if clickpads have

This is already in maverick, that commit is what broke this patch.

> multi-finger support without the multitouch patches, so a right click
> through a two finger tap may not be possible with the upstream patch.
> Unfortunately, I don't think there's a clear cut obvious resolution
> right now :(. What do others think?
>
> In the future, translation of clicks to left/middle/right buttons will
> be performed in xf86-input-synaptics based on the patch in the upstream
> kernel. Just a bit of extra info, even though that doesn't really apply
> to a released Ubuntu kernel update.
>
> -- Chase
>

When it comes to touchpads, I don't think there will be any consensus
(see the *many* bugs against xserver-xorg-input-synaptics complaining
about default settings). Looking at the Cr48 I kind of agree that an
artificial button area would be confusing, and perhaps just reverting
this completely is the right thing to do since there is no way to
disable this when it's done via this patch. Either option puts us in a
better place than the current situation though.