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

[Henrik Rydberg]

On 12/16/2010 12:22 AM, Robert Hooker wrote:

> 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.
> 


(mail got stuck at the ISP for a day)

Currently, in maverick, many of the people with no multi-finger support are
actually using the synaptics-dkms package in the utouch ppa. That package does
not have the clickpad patch, which puts some people off, but most seem to enjoy
working two-finger scrolling and such. Awaiting a finalized version of the
patches, I have not even tried to push this for maverick.

For clickpad functionality, there are several userspace solutions available, but
none of them are considered mainstream yet. Therefore, I think the patch is
still warranted for maverick, but then there should be a patch for multi-finger
support as well.

Thanks,
Henrik