# Synaptics ClickPad support [SOLVED]

## jakertberry

Hello all,

I'm working with a new HP ProBook 4520s and have been pretty happy with it. ACPI support seems a little weird, but that's for another topic. Right now I'm trying to wrap my head around this "clickpad," which is apparently a touchpad that has no buttons.

Out of the box (xorg-x11 7.3 and gentoo-sources 2.6.34-r1), the touchpad works to an extent. I can move the mouse around, scroll, and click (not tap). I am unable to right click.

I did some research and found a similar post on these forums. I applied the patch that the OP found, and it seemed to *help.* The clickpad now responds to taps, and right-clicking does work, although it's a very specific spot that's not quite in the corner, but somewhere in the bottom-right area. The major problem is when I click down, the clickpad also detects movement. This makes the clickpad almost impossible to use unless I'm clicking a large button.

(The clickpad is also very touchy when I type, but I realize that a hal policy change will fix that.)

I found various other patches that seemed to target this clickpad, but the patches either failed to apply or failed to build.

Has anyone else had any success with these clickpads?Last edited by jakertberry on Fri Jun 25, 2010 6:58 pm; edited 1 time in total

----------

## paulusbrand

The position of the buttons is described in the patch. I'll try to explain.

X goes from left to right. Y from bottom to top of you touchpad.

Y gets divided in two parts (YMIN_NOMINAL).

X gets divided in 3 parts. 

If the click (Y value) is in the lower part (hw->y < YMIN_NOMINAL) it is a button click.

If the click (X value) is in the first part ( hw->x < CLICKPAD_LEFT_BTN_X) its a left click.

If the click (X value) is in the last  part (hw->x > CLICKPAD_RIGHT_BTN_X) its a right click.

If the click (X value) is in the third part its a middle click.       

I don't know where the values for XMAX_NOMINAL and XMIN_NOMINAL and  YMIN_NOMINAL come from. I these are not correct placement of the buttons will be wrong.

The moving while tapping can probably be stopped with the "MaxTapMove" parameter. Google or type man synaptics in terminal.[/code]

----------

## jakertberry

I'm doing some tests to see if changing those values makes any difference. I guess the comment that the values "should be valid regardless of the actual size of the sensor" isn't so true on this clickpad.

There was a critical fix I had to do which made the patch work exponentially better: manually adding a line.

In synaptics.h, I had to replace the existing SYN_CAP_CLICKPAD with the line from the patch:

```
#define SYN_CAP_CLICKPAD(ec)      (SYN_CAP_PRODUCT_ID(ec) == 0xe4)

/* #define SYN_CAP_CLICKPAD(ex0c)      ((ex0c) & 0x100100) The original */
```

Now back to the buttons. With the default values, the lower half of the "buttons" act as buttons, whereas the top half act like the rest of the clickpad.

I'll tweak the NOMINAL values and see what I can come up with.

(Setting these changes in kernel is deprecated. Scroll down 2 posts.)Last edited by jakertberry on Fri Jun 25, 2010 6:58 pm; edited 1 time in total

----------

## jakertberry

Update:

Setting YMIN_NOMINAL to 2008 seems to do the trick. This value may be different for your clickpad, or you may just want to tweak it a bit. The higher the number, the higher the top edge of the "button."

(Setting these changes in the kernel is deprecated. See next post.)Last edited by jakertberry on Fri Jun 25, 2010 6:57 pm; edited 1 time in total

----------

## jakertberry

Because I love to reply to myself, and because I've been on the pursuit to making this clickpad work, I'm back again..

You can probably disregard everything I've posted previous to this, as those posts are referring to the first version of the synaptics clickpad patch.

There's two patches out there. The first one is a kernel-side hack. This patch just creates a ClickZone at the bottom of the clickpad to emulate buttons. No movement can take place here, so when you click it isn't jumpy. This patch works pretty well, although if you try to click and drag something, it's very *very* broken (and irritating to boot!).

The second patch is a little bit more involved, and was created shortly after the first patch in a heated debate between a couple devs. (Actually, it wasn't really that heated, they both agreed that moving the driver to userspace was a good idea.) With this solution, you patch the kernel so it recognizes that you have a clickpad. You then patch the xf86-input-synaptics driver to handle the rest. My experience with this patch so far has been much better. There's still a little movement when you click the clickpad, but you can at least move windows around. You can also modify how the clickpad works on the fly using synclient or HAL policies--much better than hard-coded in the kernel.

The patch for the kernel can be found at https://patchwork.kernel.org/patch/93837/. I patched against the 2.6.34-r1 kernel.

The patch for the synaptics driver can be found at https://patchwork.kernel.org/patch/92435/. I patched against the 1.2.1 driver.

After patching, recompiling, and a reboot, I had to retweak my synaptics HAL policy. 

(The buttons are in numerical order. Left click is 1, middle is 2, right is 3.)

```

   <merge key="input.x11_options.RBCornerButton" type="string">3</merge>

   <merge key="input.x11_options.LBCornerButton" type="string">1</merge>

   <merge key="input.x11_options.TapButton1" type="string">1</merge>

   <merge key="input.x11_options.TapButton3" type="string">3</merge>

```

Tweak away with synclient until you like what you see. I left out the middle button because I don't use it often enough, and because sometimes I'd accidentally tap closer towards the middle than towards a side. Setting TapButton2 to 2 will bring back a middle button.

Like all good learning experiences, I think I can now mark this as [SOLVED].   :Cool: 

----------

## 91337

I have tried your approach to this "terriffic" problem.

No success for me so far. I tried the patch for xf86-input-synaptics which seemed to run fine with version 1.2.1. 

I am having problems to get the kernel patch working though. I am trying to patch against the 2.6.35-r10-kernel and there are hunks that fail. 

Should I switch back to 2.6.34? Is this patch only compatible with 2.6.34 or am I failing at patching the kernel?

----------

## vr13

on my new HP Probook 4720s, running stable gentoo-sources-2.6.34-11@amd64 the problem was solved applying Takashi Iwai's patch https://patchwork.kernel.org/patch/93837/ for x11-drivers/xf86-input-synaptics-1.2.1:

```
ebuild /usr/portage/x11-drivers/xf86-input-synaptics/xf86-input-synaptics-1.2.1.ebuild unpack

pushd /var/tmp/portage/x11-drivers/xf86-input-synaptics-1.2.1/work/xf86-input-synaptics-1.2.1

patch -p1 < [<directory with a patch file>]some-questions-about-Synaptics-Clickpad-driver-patch.patch

popd

ebuild /usr/portage/x11-drivers/xf86-input-synaptics/xf86-input-synaptics-1.2.1.ebuild merge

```

so I did not touch neither kernel code, nor hal policies mentioned above

----------

## sparc

Hi all, I eventually fixed the clickpad support for my HP Envy 14 just by following vr13's recommendation NOT to apply the kernel patch.

However, although clicking is now working perfectly I have a new issue. Left clicking using the actual button results into double click as long I have TapButton1=1 set. Without it though I cannot use Tap clicking which is an even bigger annoyance. I have been playing around with synclient but I haven't found any option that restricts tapping to a specific area. Anybody else with a brilliant idea to save the day???

BTW, if anybody is looking into the hp envy (i7) I have to say that it is a brilliant laptop that just doesn't work yet in linux! rumor has it that 2.6.36 will solve most of the issues, although the biggest problem is the open-source ATI driver lacking support for evergreen, while suspend/resume does not work with, the otherwise great, fglrx.

----------

