| Message ID | 1292364392-6289-1-git-send-email-sarvatt@ubuntu.com |
|---|---|
| State | Accepted |
| Headers | show |
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
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>
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>
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
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.
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.
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
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);