Patchwork UBUNTU: (pre-stable): input: Support Clickpad devices in ClickZone mode

login
register
mail settings
Submitter Robert Hooker
Date Dec. 14, 2010, 10:06 p.m.
Message ID <1292364392-6289-1-git-send-email-sarvatt@ubuntu.com>
Download mbox | patch
Permalink /patch/75573/
State Accepted
Headers show

Comments

Robert Hooker - Dec. 14, 2010, 10:06 p.m.
From: Takashi Iwai <tiwai@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@suse.de>

BugLink: http://bugs.launchpad.net/bugs/516329

Acked-by: Colin King <colin.king@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>

Fixed clickpad capability checks to only check the 0x0c cap.

Signed-off-by: Robert Hooker <robert.hooker@canonical.com>
---
 drivers/input/mouse/synaptics.c |   48 +++++++++++++++++++++++++++++++++++++++
 drivers/input/mouse/synaptics.h |    1 +
 2 files changed, 49 insertions(+), 0 deletions(-)
Henrik Rydberg - Dec. 15, 2010, 10:44 a.m.
On 12/14/2010 11:06 PM, Robert Hooker wrote:

> From: Takashi Iwai <tiwai@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@suse.de>
> 
> BugLink: http://bugs.launchpad.net/bugs/516329
> 
> Acked-by: Colin King <colin.king@canonical.com>
> Acked-by: Andy Whitcroft <apw@canonical.com>
> Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
> Signed-off-by: Andy Whitcroft <apw@canonical.com>
> 
> Fixed clickpad capability checks to only check the 0x0c cap.
> 
> Signed-off-by: Robert Hooker <robert.hooker@canonical.com>
> ---


Just a heads-up that this will conflict again as we move to 2.6.38.

Thanks,
Henrik
Tim Gardner - Dec. 15, 2010, 2:06 p.m.
On 12/15/2010 03:44 AM, Henrik Rydberg wrote:
> On 12/14/2010 11:06 PM, Robert Hooker wrote:
>
>> From: Takashi Iwai<tiwai@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@suse.de>
>>
>> BugLink: http://bugs.launchpad.net/bugs/516329
>>
>> Acked-by: Colin King<colin.king@canonical.com>
>> Acked-by: Andy Whitcroft<apw@canonical.com>
>> Signed-off-by: Chase Douglas<chase.douglas@canonical.com>
>> Signed-off-by: Andy Whitcroft<apw@canonical.com>
>>
>> Fixed clickpad capability checks to only check the 0x0c cap.
>>
>> Signed-off-by: Robert Hooker<robert.hooker@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)

Acked-by: Tim Gardner <tim.gardner@canonical.com>
Brad Figg - Dec. 15, 2010, 4:24 p.m.
On 12/15/2010 06: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@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@suse.de>
>>>
>>> BugLink: http://bugs.launchpad.net/bugs/516329
>>>
>>> Acked-by: Colin King<colin.king@canonical.com>
>>> Acked-by: Andy Whitcroft<apw@canonical.com>
>>> Signed-off-by: Chase Douglas<chase.douglas@canonical.com>
>>> Signed-off-by: Andy Whitcroft<apw@canonical.com>
>>>
>>> Fixed clickpad capability checks to only check the 0x0c cap.
>>>
>>> Signed-off-by: Robert Hooker<robert.hooker@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)
>
> Acked-by: Tim Gardner<tim.gardner@canonical.com>
>

Just to be clear, the only difference between the reverted patch and
the new one are the two line changes that Robert has made to the original
patch by Takashi.

Acked-by: Brad Figg<brad.figg@canonical.com>
Chase Douglas - Dec. 15, 2010, 10 p.m.
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@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@suse.de>
>>>
>>> BugLink: http://bugs.launchpad.net/bugs/516329
>>>
>>> Acked-by: Colin King<colin.king@canonical.com>
>>> Acked-by: Andy Whitcroft<apw@canonical.com>
>>> Signed-off-by: Chase Douglas<chase.douglas@canonical.com>
>>> Signed-off-by: Andy Whitcroft<apw@canonical.com>
>>>
>>> Fixed clickpad capability checks to only check the 0x0c cap.
>>>
>>> Signed-off-by: Robert Hooker<robert.hooker@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
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
Robert Hooker - Dec. 15, 2010, 11:22 p.m.
On Wed, Dec 15, 2010 at 5:00 PM, Chase Douglas
<chase.douglas@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@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@suse.de>
>>>>
>>>> BugLink: http://bugs.launchpad.net/bugs/516329
>>>>
>>>> Acked-by: Colin King<colin.king@canonical.com>
>>>> Acked-by: Andy Whitcroft<apw@canonical.com>
>>>> Signed-off-by: Chase Douglas<chase.douglas@canonical.com>
>>>> Signed-off-by: Andy Whitcroft<apw@canonical.com>
>>>>
>>>> Fixed clickpad capability checks to only check the 0x0c cap.
>>>>
>>>> Signed-off-by: Robert Hooker<robert.hooker@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.
Brad Figg - Dec. 16, 2010, 5:32 a.m.
On 12/14/2010 02:06 PM, Robert Hooker wrote:
> From: Takashi Iwai<tiwai@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@suse.de>
>
> BugLink: http://bugs.launchpad.net/bugs/516329
>
> Acked-by: Colin King<colin.king@canonical.com>
> Acked-by: Andy Whitcroft<apw@canonical.com>
> Signed-off-by: Chase Douglas<chase.douglas@canonical.com>
> Signed-off-by: Andy Whitcroft<apw@canonical.com>
>
> Fixed clickpad capability checks to only check the 0x0c cap.
>
> Signed-off-by: Robert Hooker<robert.hooker@canonical.com>
> ---
>   drivers/input/mouse/synaptics.c |   48 +++++++++++++++++++++++++++++++++++++++
>   drivers/input/mouse/synaptics.h |    1 +
>   2 files changed, 49 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 705589d..ae9891c 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -357,6 +357,45 @@ static void synaptics_pt_create(struct psmouse *psmouse)
>    *	Functions to interpret the absolute mode packets
>    ****************************************************************************/
>
> +/* left and right clickpad button ranges;
> + * the gap between them is interpreted as a middle-button click
> + */
> +#define CLICKPAD_LEFT_BTN_X \
> +	((XMAX_NOMINAL - XMIN_NOMINAL) * 2 / 5 + XMIN_NOMINAL)
> +#define CLICKPAD_RIGHT_BTN_X \
> +	((XMAX_NOMINAL - XMIN_NOMINAL) * 3 / 5 + XMIN_NOMINAL)
> +
> +/* handle clickpad events */
> +static void clickpad_process_packet(struct synaptics_data *priv,
> +				    struct synaptics_hw_state *hw)
> +{
> +	/* clickpad mode reports Y range from 0 to YMAX_NOMINAL,
> +	 * where the area Y<  YMIN_NOMINAL is used as click buttons
> +	 */
> +	if (hw->y<  YMIN_NOMINAL) {
> +		/* button area */
> +		hw->z = 0; /* don't move pointer */
> +		/* clickpad reports only the middle button, and we need
> +		 * to fake left/right buttons depending on the touch position
> +		 */
> +		if (hw->middle) { /* clicked? */
> +			hw->middle = 0;
> +			if (hw->x<  CLICKPAD_LEFT_BTN_X)
> +				hw->left = 1;
> +			else if (hw->x>  CLICKPAD_RIGHT_BTN_X)
> +				hw->right = 1;
> +			else
> +				hw->middle = 1;
> +		}
> +	} else if (hw->middle) {
> +		/* dragging */
> +		hw->left = priv->prev_hw.left;
> +		hw->right = priv->prev_hw.right;
> +		hw->middle = priv->prev_hw.middle;
> +	}
> +	priv->prev_hw = *hw;
> +}
> +
>   static void synaptics_parse_hw_state(unsigned char buf[], struct synaptics_data *priv, struct synaptics_hw_state *hw)
>   {
>   	memset(hw, 0, sizeof(struct synaptics_hw_state));
> @@ -445,6 +484,9 @@ static void synaptics_process_packet(struct psmouse *psmouse)
>
>   	synaptics_parse_hw_state(psmouse->packet, priv,&hw);
>
> +	if (SYN_CAP_CLICKPAD(priv->ext_cap_0c))
> +		clickpad_process_packet(priv,&hw);
> +
>   	if (hw.scroll) {
>   		priv->scroll += hw.scroll;
>
> @@ -748,6 +790,12 @@ int synaptics_init(struct psmouse *psmouse)
>   		SYN_ID_MAJOR(priv->identity), SYN_ID_MINOR(priv->identity),
>   		priv->model_id, priv->capabilities, priv->ext_cap, priv->ext_cap_0c);
>
> +	if (SYN_CAP_CLICKPAD(priv->ext_cap_0c)) {
> +		printk(KERN_INFO "Synaptics: Clickpad mode enabled\n");
> +		/* force to enable the middle button */
> +		priv->capabilities |= (1<<  18);
> +	}
> +
>   	set_input_params(psmouse->dev, priv);
>
>   	/*
> diff --git a/drivers/input/mouse/synaptics.h b/drivers/input/mouse/synaptics.h
> index b6aa7d2..80907d0 100644
> --- a/drivers/input/mouse/synaptics.h
> +++ b/drivers/input/mouse/synaptics.h
> @@ -110,6 +110,7 @@ struct synaptics_data {
>   	unsigned char pkt_type;			/* packet type - old, new, etc */
>   	unsigned char mode;			/* current mode byte */
>   	int scroll;
> +	struct synaptics_hw_state prev_hw;
>   };
>
>   void synaptics_module_init(void);

Applied and pushed to Maverick master-next.
Henrik Rydberg - Dec. 16, 2010, 1:48 p.m.
On 12/16/2010 12:22 AM, Robert Hooker wrote:

> On Wed, Dec 15, 2010 at 5:00 PM, Chase Douglas
> <chase.douglas@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@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@suse.de>
>>>>>
>>>>> BugLink: http://bugs.launchpad.net/bugs/516329
>>>>>
>>>>> Acked-by: Colin King<colin.king@canonical.com>
>>>>> Acked-by: Andy Whitcroft<apw@canonical.com>
>>>>> Signed-off-by: Chase Douglas<chase.douglas@canonical.com>
>>>>> Signed-off-by: Andy Whitcroft<apw@canonical.com>
>>>>>
>>>>> Fixed clickpad capability checks to only check the 0x0c cap.
>>>>>
>>>>> Signed-off-by: Robert Hooker<robert.hooker@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

Patch

diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 705589d..ae9891c 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -357,6 +357,45 @@  static void synaptics_pt_create(struct psmouse *psmouse)
  *	Functions to interpret the absolute mode packets
  ****************************************************************************/
 
+/* left and right clickpad button ranges;
+ * the gap between them is interpreted as a middle-button click
+ */
+#define CLICKPAD_LEFT_BTN_X \
+	((XMAX_NOMINAL - XMIN_NOMINAL) * 2 / 5 + XMIN_NOMINAL)
+#define CLICKPAD_RIGHT_BTN_X \
+	((XMAX_NOMINAL - XMIN_NOMINAL) * 3 / 5 + XMIN_NOMINAL)
+
+/* handle clickpad events */
+static void clickpad_process_packet(struct synaptics_data *priv,
+				    struct synaptics_hw_state *hw)
+{
+	/* clickpad mode reports Y range from 0 to YMAX_NOMINAL,
+	 * where the area Y < YMIN_NOMINAL is used as click buttons
+	 */
+	if (hw->y < YMIN_NOMINAL) {
+		/* button area */
+		hw->z = 0; /* don't move pointer */
+		/* clickpad reports only the middle button, and we need
+		 * to fake left/right buttons depending on the touch position
+		 */
+		if (hw->middle) { /* clicked? */
+			hw->middle = 0;
+			if (hw->x < CLICKPAD_LEFT_BTN_X)
+				hw->left = 1;
+			else if (hw->x > CLICKPAD_RIGHT_BTN_X)
+				hw->right = 1;
+			else
+				hw->middle = 1;
+		}
+	} else if (hw->middle) {
+		/* dragging */
+		hw->left = priv->prev_hw.left;
+		hw->right = priv->prev_hw.right;
+		hw->middle = priv->prev_hw.middle;
+	}
+	priv->prev_hw = *hw;
+}
+
 static void synaptics_parse_hw_state(unsigned char buf[], struct synaptics_data *priv, struct synaptics_hw_state *hw)
 {
 	memset(hw, 0, sizeof(struct synaptics_hw_state));
@@ -445,6 +484,9 @@  static void synaptics_process_packet(struct psmouse *psmouse)
 
 	synaptics_parse_hw_state(psmouse->packet, priv, &hw);
 
+	if (SYN_CAP_CLICKPAD(priv->ext_cap_0c))
+		clickpad_process_packet(priv, &hw);
+
 	if (hw.scroll) {
 		priv->scroll += hw.scroll;
 
@@ -748,6 +790,12 @@  int synaptics_init(struct psmouse *psmouse)
 		SYN_ID_MAJOR(priv->identity), SYN_ID_MINOR(priv->identity),
 		priv->model_id, priv->capabilities, priv->ext_cap, priv->ext_cap_0c);
 
+	if (SYN_CAP_CLICKPAD(priv->ext_cap_0c)) {
+		printk(KERN_INFO "Synaptics: Clickpad mode enabled\n");
+		/* force to enable the middle button */
+		priv->capabilities |= (1 << 18);
+	}
+
 	set_input_params(psmouse->dev, priv);
 
 	/*
diff --git a/drivers/input/mouse/synaptics.h b/drivers/input/mouse/synaptics.h
index b6aa7d2..80907d0 100644
--- a/drivers/input/mouse/synaptics.h
+++ b/drivers/input/mouse/synaptics.h
@@ -110,6 +110,7 @@  struct synaptics_data {
 	unsigned char pkt_type;			/* packet type - old, new, etc */
 	unsigned char mode;			/* current mode byte */
 	int scroll;
+	struct synaptics_hw_state prev_hw;
 };
 
 void synaptics_module_init(void);