[Jaunty] MacBook 5.1 touchpad not fully supported

[Chris Lasher]

Binary package hint: xorg

The touchpad for MacBook 5.1 is not supported completely in Jaunty (Ubuntu 9.04) as of Alpha 5 release. The pointer can move, and a physical left-click works, but that's it. I can not get tapping to respond as I could using the Mactel PPA packages with Intrepid (Ubuntu 8.10). I added the attached FDI policy file for the touchpad, and manually added the module bcm5974 to my /etc/modules file, however, Xorg is not loading or is not recognizing the touchpad policies. This file worked on Intrepid. The custom bcm5974-dkms package from the Mactel PPA provided support in Intrepid.

[Bryce Harrington (bryce)]

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

[Chris Lasher (chris.lasher)]

Sure thing.

[Chris Lasher (chris.lasher)]

Here I attach my current Xorg file, which uses the nVIDIA restricted driver. The conditions remain with this xorg.conf.

[Chris Lasher (chris.lasher)]

My original xorg.conf file from the out of the box install was completely empty, apparently. As such I can't actually attach it here in Launchpad. Suffice to say, I experienced the touchpad issue using the empty xorg.conf file, even when supplying the fdi file for the hal policy.

[Alex Karpenko (alexkarpenko)]

Could this be related to this bug:
https://bugs.edge.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/336523

[Chris Lasher (chris.lasher)]

Quite possibly. Some differences:

* `grep bcm5974 /proc/bus/input/devices` returns nothing (I'm attaching the file). This could be rather important--this device should show up here, no? I do have that module loaded, as confirmed by the lsmod attached above.
* xserver-xorg-input-synaptics is installed by default in Jaunty Alpha 5.

[Ricky Campbell (cyberdork33)]

This a different bug. In my bug, the touchpad would not work at all because synaptics did not install by default. This bug still seems to affect me even after fixing the other bug. The issue here is that the fdi policy file seems to be completely ignored. I haven't looked too deeply into my configuration yet though. There seems to be some "pre-set" config and that is the only config that works.

[Chris Lasher (chris.lasher)]

Can I provide any more information to help?

[Ricky Campbell (cyberdork33)]

any reason this was decided invalid against synaptics?

[Chris Lasher (chris.lasher)]

Still no luck with this, despite several kernel and Xorg updates.

[Bryce Harrington (bryce)]

XOrg-Driver-Synaptics is not the correct package name for -synaptics.

[Ed K (ekohlwey)]

I'm also experiencing this issue. Opening up xev the trackpad doesn't produce any events on anything other than left click (I don't know if it should be expected to if the problem is simply that the FDI is not being utilized).

[Henrik Rydberg (rydberg)]

Ed K wrote:
> I'm also experiencing this issue. Opening up xev the trackpad doesn't
> produce any events on anything other than left click (I don't know if it
> should be expected to if the problem is simply that the FDI is not being
> utilized).
>

The jaunty kernel does not include the necessary changes for the
MacBook5-1 to work, but the bcm5974-dkms package solves the problem and
is now available in the Mactel PPA.

Henrik

[P. Dunbar (vigilcode)]

I've installed the bcm5974-dkms for jaunty from the mactel ppa and still can not get any .fdi profiles to do anything.

[Henrik Rydberg (rydberg)]

P. Dunbar wrote:
> I've installed the bcm5974-dkms for jaunty from the mactel ppa and still
> can not get any .fdi profiles to do anything.
>

The conjecture is that the built-in HID module is stealing the mouse
interface. To confirm, please reboot and attach the full output of dmesg.

Henrik

[Ricky Campbell (cyberdork33)]

I think someone in the forum mentioned that hal was not loading before xorg or something which cause xorg to not see the hardware properly. I can't seem to find the post now. He editted the number of the script so that it would load in the right order.

[P. Dunbar (vigilcode)]

Here is my dmesg output on a clean boot.

[Henrik Rydberg (rydberg)]

P. Dunbar wrote:
> Here is my dmesg output on a clean boot.
>
> ** Attachment added: "dmesg output"
> http://launchpadlibrarian.net/24189298/dmesg.out
>

Mm, this line says the trackpad is added as a raw input device:

[ 10.121135] apple 0003:05AC:0236.0002: input,hidraw2: USB HID v1.11
Keyboard [Apple, Inc. Apple Internal Keyboard / Trackpad] on
usb-0000:00:04.0-6/input0

So, most likely, bcm5974 cannot claim the device. To confirm, it should
suffice to see that the line below returns no output:

grep bcm5974 /proc/bus/input/devices

The problem is that I cannot off-hand think of a way to set the
ignore-mouse quirks in the jaunty kernel; things were moved around quite
a bit, and it seems to me some of the quirks possibilities were removed.
Compiling a custom kernel is of course always an option.

Henrik

[P. Dunbar (vigilcode)]

confirmed. bcm5974 is not in /proc/bus/input/devices

[Ed K (ekohlwey)]

On a fresh install of Jaunty a6 hal starts in runlevel 2, and x11-common starts in runlevel 5, so the hal/X11 trick is probably not a valid workaround.

Should this be entered as a bug or question for the Jaunty kernel?

[P. Dunbar (vigilcode)]

It seems at this point that the kernel is where this would have to be fixed.
which means if you want a fully working touchpad on your mac you'd might want to use intrepid cause I doubt kernel modifications will come any time soon for this.

[Alex Murray (alexmurray)]

Mm, this line says the trackpad is added as a raw input device:

[ 10.121135] apple 0003:05AC:0236.0002: input,hidraw2: USB HID v1.11
Keyboard [Apple, Inc. Apple Internal Keyboard / Trackpad] on
usb-0000:00:04.0-6/input0

-- Is there a way to blacklist usbhid so it does not claim the device, to instead allow bcm5974 to claim it?

[Ed K (ekohlwey)]

It seems to me like blacklisting usbhid is a poor workaround... wouldn't that prevent you from using external mice, etc. in the usual way (ie, plug it in and it works)?

Would it be possible for mactel support to continue to provide a patched usbhid kernel module (as I assume the case had been prior to the patch that removed the usbhid dependency?). That seems like an appropriate workaround until there is movement on the kernel end. If the issue is simply getting someone to help maintain a new package, is there any mentoring support available?

[Eric Johney (ericjohney)]

I can confirm blacklisting usbhid worked for me. I simply made a blacklist entry for usbhid and then in /etc/modules I loaded bcm5974 and then usbhid.

That way usbhid still gets loaded, but after bcm5974

[Ricky Campbell (cyberdork33)]

Good idea Eric. I think that is easier than maintaining a package.

usbhid code is at bitmath.org git repo though...
http://bitmath.org/code/usbhid-dkms/

[Henrik Rydberg (rydberg)]

Ricky Campbell wrote:
> Good idea Eric. I think that is easier than maintaining a package.

I'm glad you found a workaround, since this problem got tougher with the
new 2.6.28 kernel.

>
> usbhid code is at bitmath.org git repo though...
> http://bitmath.org/code/usbhid-dkms/
>

The possibility to control the mouse interface was moved to the hid
module, which is now built into the kernel. You'd have to hack the
usbhid module with something like this
untested-and-not-compiled-and-unsupported piece of code:

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 606369e..2fe49ab 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1012,7 +1012,15 @@ static int hid_probe(struct usb_interface *intf,
const struct usb_device_id *id
        hid->driver_data = usbhid;
        usbhid->hid = hid;

- ret = hid_add_device(hid);
+ /* ignore the mouse interface of the WELLSPRING3 devices */
+ if (hid->type == HID_TYPE_USBMOUSE &&
+ hid->vendor = 0x05ac &&
+ (hid->product == 0x0236 ||
+ hid->product == 0x0237 ||
+ hid->product == 0x0238))
+ ret = -ENODEV;
+ else
+ ret = hid_add_device(hid);
        if (ret) {
                if (ret != -ENODEV)
                        dev_err(&intf->dev, "can't add hid device:
%d\n", ret);

I am leaving this snippet as a pointer to a possible solution for anyone
who feels like picking it up. Please understand that I will not
regularly answer emails regarding this or other jaunty issues. I will
hopefully see you gentlemen during the karmic work, as that is the next
release I will involve myself in.

So long,
Henrik

[Ed K (ekohlwey)]

I can confirm that Eric's workaround worked for me too.

[Ricky Campbell (cyberdork33)]

Great. Can someone edit the wiki page here appropriately so that can be closed against Mactel-Support?
https://help.ubuntu.com/community/MacBook5-1/Jaunty#Trackpad

[Ed K (ekohlwey)]

The wiki has been updates appropriately.

[TheRealBigApple (therealbigapple)]

This affects *also* MacBookPro (4,1)! Thanks for the workaround.

[Ricky Campbell (cyberdork33)]

Great! I thought this might affect the MacBookPro4,1 as well. It is probably likely that it affects the MacBook(Pro)5.x models as well since they use the same touchpad driver.

[Jim Rorie (jfrorie)]

Workaround disables the keyboard in Jaunty Beta, both internal and external USB keyboards. Removal of the policy file restores normal keyboard functioning.

[Jim Rorie (jfrorie)]

Sorry, macbook pro 5,1

[P. Dunbar (vigilcode)]

Use the attached .fdi file.
I was messing with this last night and some of the .fdi files I used on the wiki above or this wiki https://help.ubuntu.com/community/MacBookPro4-1/Jaunty
caused me the same behavior.
I was just ready to update this wiki: https://help.ubuntu.com/community/MacBookPro5-1_5-2/Jaunty
with what is working on my MacBookPro5,2.

[Colin D Bennett (colinb)]

I got the trackpad on my MacBook Pro 5,1 *mostly* working by doing:
(On a fresh install of Jaunty Beta)

1. Install all the mactel PPA packages.
2. Blacklist usbhid
3. Put bcm5974, usbhid in modprobe's "modules" file to force bcm5974 to load first.
4. Put the file posted above by P. Dunbar on 2009-03-31 in /etc/hal/fdi/policy

I could then tweak the .fdi file in a minor way and had the following features:

- tap-to-click
- one/two/three-finger tap clicks for left/right/middle button
- two-finger scrolling (both vertical and horizontal)

There are still some big problems that make the trackpad completely unusable for me unfortunately. The main problems are:

1. Sensitivity is *WAY* too low.
2. Can't click and hold with thumb while dragging with another finger.

First, the sensitivity problem. I tweaked the .fdi file's MinSpeed, MaxSpeed, and AccelFactor to achieve much higher speed of movement that is fairly satisfactory -- however, this only has an effect at the GDM login screen! When I actually log in and Gnome starts, the trackpad movement slows down tremendously. Even if I crank up the sensitivity/acceleration in the Preferences|Mouse dialog, it is still too slow. Also, I don't want much "acceleration" I mostly want a constant, moderate sensitivity. This is useful because the MacBook Pro's trackpad is so enormous (which is one of the features that made me choose this laptop).

I cannot use the 'synclient' program, it always says that it can't access the shared memory segment and I should enable SHM support in the synaptics configuration, but it is already enabled in the .fdi file. (Also, there is nothing related to this in the xorg.conf file that could be messing it up.) I tried the 'gpointing-device-settings' program (http://live.gnome.org/GPointingDeviceSettings) and this provided some easy access to extremely important xinput settings such as palm detection. It did not allow configuring the sensitivity or speed of the trackpad movement.

I would be very happy if the trackpad movement speed at the GDM login screen could simply be preserved when I logged in. Does anyone have an idea how I could do this?

Second, the normal way of dragging things that I use in Mac OS X does not work. I find that double-tap-and-drag is sometimes useful but can be finicky if you don't wait long enough before putting your finger back down after you are done dragging (it will think you still want to drag). I have this problem in Mac OS X too. So I find the most effective way to drag is to use my forefinger to move the pointer and click-and-hold with my thumb on the near edge of the trackpad while I drag with the forefinger. This does not work in Ubuntu; apparently the driver is confused by my thumb's presence on the trackpad surface.

I think that Mac OS X must treat the near (bottom) edge of the trackpad specially when a second finger is detected there, in order to support the particular case where the thumb is used to click in the region on the bottom edge while a finger is moving the pointer elsewhere on the trackpad. I'd be willing to implement this functionality myself if someone could give me a nudge in the right direction; I don't ...

[P. Dunbar (vigilcode)]

I don't seem to have a big sensitivity problem. I am currenlty using the .fdi file I have on the wiki (not sure if its the same I uploaded here at this point).
My big issue with the touchpad is the dragging as you mentioned as well. In Mac OSX I primarily will drag with holding my thumb clicked down on the bottom and moving my finger above that for the drag. I can continuously lift up my finger and put it down to keep the drag going. I can't get anywhere close to this functionality and I've tried a lot.
I also then tried to get coasting working, figuring if I can't drag that way at least if I hit the bottom of my touchpad while dragging and still want to drag more it would continue to drag. Again, I tried setting these settings in the .fdi and they seemed to do nothing at all. So i'm beginning to think that only some of the functionality you can use detailed withing 'man synaptics' is actually picked up or used by this current bcm5974.
Any ideas welcome.

[Erkin Bahceci (cornelius1)]

Here is a patch for bcm5974-dkms to make click-and-drag work with Macbook 5,1. When clicking with two fingers touching the trackpad, it simply ignores the finger that is doing the clicking (the one that is relatively lower on the touchpad), just like OS X does. It does *not* disable the bottom part (to make it act only as a button). It also does not change the behavior of other trackpad models, or the cases when the user is not clicking or is clicking with any number of fingers other than two.

The only caveat is that now you can't right-click by two-finger-clicking and instead you need to do it by two-finger-tapping by enabling the TapButton for right-click, as in the attached policy file. This is actually a behavior that makes sense and what happens in OS X anyway, since when you are clicking and have two fingers on the touchpad, you are expected to be doing a click-and-drag, not a right-click. In fact, OS X does not even have a "right-click by two-finger-clicking" feature as it would interfere with click-and-drag. Thus, this shouldn't be a problem.

Attached is the patch, a package for testing, and a policy file that has fast taps and tap buttons enabled.

[Erkin Bahceci (cornelius1)]

Apparently, OS X does have the ability to do a right-click by two-finger-clicking feature (enabled together with two-finger-tapping). Doing the same will require some state tracking. Something to look into next. Still, the patch should improve the current experience as long as two-finger tapping is enabled.

[Ricky Campbell (cyberdork33)]

I would say that this patch and associated "feature request" be put into another bug report since this bug is really about getting the fdi file to work at all, not modifying the touchpad driver to add/remove functionality.

[Erkin Bahceci (cornelius1)]

I removed the patch and the package here as I created a new bug report with an improved version of the patch that does not break two-finger-clicking and makes the behavior similar to OS X:
https://bugs.edge.launchpad.net/mactel-support/+bug/356317

[Colin D Bennett (colinb)]

@P. Dunbar: OK, the problem was actually that my .fdi file was not taking effect! So SHMConfig was defaulted to false and all my settings had no effect. I grabbed the .fdi file off the wiki and started fresh, and got it working better. The sensitivity is great now.

[Νίκος Αλεξανδρής (nikos.alexandris)]

This "bug" affects also MacBook Pro 5,1.

[TheRealBigApple (therealbigapple)]

I just reinstalled Ubuntu 9.04 Beta on my MacBookPro (4,1) and found out that right click is working (without mactel-support or any patches) if you put *three* fingers on the touchpad and the click anywhere... Can anyone confirm that for another model?

[Ricky Campbell (cyberdork33)]

yes. It was that way for me since I have been using Jaunty.

3 finger tap should also work.

2-fingers is middle click I think.

[acron (johannes-dohmen)]

1. I would like to confirm the existence this bug in the final version of jaunty.
2. Eric's walkaround didn't work for me until I run:
sudo depmod -ae
sudo update-initramfs -u

Could someone update the wiki with that?
Btw the MacBook5-1/Jaunty-Page is not linked from here https://wiki.ubuntu.com/MactelSupportTeam/CommunityHelpPages but it should, shouldn't it?

[Ricky Campbell (cyberdork33)]

acron,

if you see things that should be added to a wiki page, go for it. That is the idea of wiki pages.

[Νίκος Αλεξανδρής (nikos.alexandris)]

Johannes,

thanks. That (meaning depmod & update-initramfs) did the trick for me as well :-).
Cheers, Nikos

[acron (johannes-dohmen)]

Ricky,

thanks, good point ;-) I updated the wiki with the info.
I wasn't sure if some kind of privileges would be needed to edit the wiki but there weren't...

[acron (johannes-dohmen)]

I think the bug has been fixed in the update. At least I cannot reproduce it anymore.
See the changelog here:
https://launchpad.net/~mactel-support/+archive/ppa/+sourcepub/612058/+listing-archive-extra

So maybe someone wants to close this bug?

[Ricky Campbell (cyberdork33)]

acron, those are community-made packages. This fix is still an issue for Ubuntu.

[Jim Rorie (jfrorie)]

Tapping and two finger scroll/context menu appear to be working as of Karmic Alpha 6. Both features are accessible in default install and controllable under preferences. Two things of note:

1) Hal policy file values for FingerLow and FingerHigh appear to be ignored. My touchpad will track my fingers 3mm above the surface. Very difficult to use.

2) The sensitivity slider appears to work backwards. More sensitivity appears to slow the cursor down.

[MM (mmme)]

On a 13" Macbook Pro 5.5 I followed all the steps and nothing worked for me. :(

Making a .fdi file found on the Karmic Wiki:

https://help.ubuntu.com/community/MacBookPro5-5/Karmic?highlight=%28%28MacBookPro5-5|Karmic%29%29

Blacklisting usbhid then in /etc/modules then loading bcm5974 and then usbhid.

[Martin von Gagern (gagern)]

Doesn't work out of the box for me on current Karmic Beta, as Jim Rorie claims. It used to work on Intrepid with some additional packages from the Mactel Support PPA, but I deliberately dropped all PPA packages after updating to Karmic, and even moved the fdi file I had created on Intrepid. So my system should be a fair approximation of an "out of the box" set-up. Hardware is a Macbook Pro 5,1.

[Alberto Milone (albertomilone)]

The package in the PPA is really a kernel module. It could be that the version of that driver that we have in the kernel is a bit dated.

[Martin von Gagern (gagern)]

Unfortunately the bcm5974-dkms PPA module is delivered as full text source, not as a patch against some underlying kernel source. So when comparing that file to the one in the current kernel, and as I don't know the common ancestor, I don't know which modifications were introduced in the kernel since then, and which were deliberate for the dkms module. Looking at the kernel git history, I get the impression that both drivers include the same kind of features, although not in the same wording. Therefore the kernel driver seems recent enough to me.

I just found out that by simply adjusting some settings using synclient, I could get tapping to work. So it seems that the default config simply doesn't provide OS-X-like behaviour, and that furthermore the settings from my own fdi file weren't used for some reason. Investigating that now...

[Martin von Gagern (gagern)]

Stupid me: it's the Gnome settings which disabled taps and stuff like that. I just found out that with my fdi file in place, taps worked all right in the gdm login screen, but failed once the session was started. I found the corresponding settings in System / Settings / Mouse / Touchpad.

So I take back my complaints: things work, only the Mactel guides talking about fdi files need adjusting, as settings are now per-user and not per-system. If you can manage to log in without those settings, that is.

[Jim Rorie (jfrorie)]

>
> So I take back my complaints: things work, only the Mactel guides
> talking about fdi files need adjusting, as settings are now per-user
> and
> not per-system. If you can manage to log in without those settings,
> that
> is.
>

Martin,

Could you be more specific about the per user/per session changes? I will
make the necessary mods to the documentation...

[Alberto Milone (albertomilone)]

Martin:
doesn't that touchpad have physical buttons?

If it doesn't have buttons then the gnome-settings-daemon should enable tap-to-click by default (only in this case)

[Martin von Gagern (gagern)]

I'll try. The current docs describe how you should place a file in /etc/hal/fdi/policy/ in order to enable tapping and two-finger scrolling and such stuff. While this is still true for the initial settings of the X server, once a user logs in, gnome-settings-daemon overwrites these initial settings with settings derived from the user configuration. I'm not sure how other desktop environments, in particular KDE, would deal with this situation, so perhaps there should be a note about the fact that initial config is determined by a hal fdi policy file.

Gnome users shouldn't have to bother, though. Instead, they could run gnome-mouse-properties, choose the Touchpad tab, and enable tap to click, choose two-finger scrolling as their desired scroll method, and also enable horizontal scrolling. Settings will take effect immediately. If tap to click is enabled, tap and drag (discussed in bug #356317) seems to work out of the box.

The current settings of these configuration items can also be obtained on the command line:
gconftool -R /desktop/gnome/peripherals/touchpad
The output might be useful in bug reports. Of course it would also be possible to set these values programmatically, but I guess there is little point for most users.

gnome-settings-daemon communicates with the device driver through X device properties, listed in the synaptics(4) man page, as does synclient without the -s. Therefore users can install synclient to have a look at current configuration ("synclient -l"), and to change settings not readily accessible through the Gnome control center, like e.g. circular scrolling. I don't know what would be the most gnomish way to make such settings persistent on a per-user basis, though. fdi files would work for these as well, I guess.

One thing that still doesn't work as expected is the button integrated into the touchpad. Under OS X, I can use one finger to move the cursor and another finger to press the front part of the touchpad, generating a left or right click depending on the part of the touchpad I pressed. On Ubuntu, both fingers contribute to cursor movement, and the button always works as button 1. So in that respect, the touchpad is still not fully functional on Karmic beta. Want a separate report for that aspect?

[Jim Rorie (jfrorie)]

Ok, If I understand this correctly, you are saying that the hal
configuration file is only used for X. Gnome is controlled through
gnome-settings-demon and most of the settings are changed through gconf
or menu. You are not sure about KDE. Synclient controls extended
values. I assume these values are put in the xorg.conf file.

Under Ubuntu, if you click using two fingers, the context menu appears.
I'm not sure if that is expected behavior, that's always the way it has
worked for me. I've never used OSX so I can't comment on the clicking a
specific area.

The one thing I'm still seeing is the second finger high/low
sensitivity. Is there a setting in synclient for the
fingerhigh/fingerlow for the second finger? I can set it to 200 and the
single finger works fine and I have to press hard, but if another finger
grazes the pad, it registers. I'm thinking this is just a flat out bug.

On Tue, 2009-10-13 at 12:53 +0000, Martin von Gagern wrote:
> I'll try. The current docs describe how you should place a file in
> /etc/hal/fdi/policy/ in order to enable tapping and two-finger scrolling
> and such stuff. While this is still true for the initial settings of the
> X server, once a user logs in, gnome-settings-daemon overwrites these
> initial settings with settings derived from the user configuration. I'm
> not sure how other desktop environments, in particular KDE, would deal
> with this situation, so perhaps there should be a note about the fact
> that initial config is determined by a hal fdi policy file.
>
> Gnome users shouldn't have to bother, though. Instead, they could run
> gnome-mouse-properties, choose the Touchpad tab, and enable tap to
> click, choose two-finger scrolling as their desired scroll method, and
> also enable horizontal scrolling. Settings will take effect immediately.
> If tap to click is enabled, tap and drag (discussed in bug #356317)
> seems to work out of the box.
>
> The current settings of these configuration items can also be obtained on the command line:
> gconftool -R /desktop/gnome/peripherals/touchpad
> The output might be useful in bug reports. Of course it would also be possible to set these values programmatically, but I guess there is little point for most users.
>
> gnome-settings-daemon communicates with the device driver through X
> device properties, listed in the synaptics(4) man page, as does
> synclient without the -s. Therefore users can install synclient to have
> a look at current configuration ("synclient -l"), and to change settings
> not readily accessible through the Gnome control center, like e.g.
> circular scrolling. I don't know what would be the most gnomish way to
> make such settings persistent on a per-user basis, though. fdi files
> would work for these as well, I guess.
>
> One thing that still doesn't work as expected is the button integrated
> into the touchpad. Under OS X, I can use one finger to move the cursor
> and another finger to press the front part of the touchpad, generating a
> left or right click depending on the part of the touchpad I pressed. On
> Ubuntu, both fingers contribute to cursor movement, and the button
> always works as button 1. So in that respec...

[Martin von Gagern (gagern)]

Jim Rorie wrote:
> Ok, If I understand this correctly, you are saying that the hal
> configuration file is only used for X. Gnome is controlled through
> gnome-settings-demon and most of the settings are changed through gconf
> or menu. You are not sure about KDE.

Correct.

> Synclient controls extended values.

All values, in fact, so if you wanted to, you could configure everything
through synclient. Could happen that gnome-settings-daemon would
interfere for the basic settings, though, so in reality this is not a
good suggestion.

> I assume these values are put in the xorg.conf file.

As xorg.conf requires root access and synclient only has user access, I
assume it's only in the in-memory driver configuration.

> Under Ubuntu, if you click using two fingers, the context menu appears.
> I'm not sure if that is expected behavior, that's always the way it has
> worked for me. I've never used OSX so I can't comment on the clicking a
> specific area.

It's configurable under OS X. I guess the default for this was off, and
would be OK for users who only ever use apps designed for OS X. But most
users of cross-platform apps would probably have enabled the two-finger
right-click if they enabled the single-finger left-click. And on Linux I
believe you definitely want a secondary click, and the built-in mouse
button currently isn't up to this.

> Is there a setting in synclient for the
> fingerhigh/fingerlow for the second finger?

No.

> I'm thinking this is just a flat out bug.

Yes, but where? Is it the firmware (not able to determine independent
pressures), the kernel driver (not passing information received from the
hardware), the protocol (unable to transmit multiple pressure values) or
the X driver (not implementing such a config option)? I don't know.

[Glyph Lefkowitz (glyph)]

It seems like there's a lot of noise on this bug; for what it's worth, I'm only really interested in one of the things mentioned in #38 <https://bugs.launchpad.net/linux/+bug/337935/comments/38>, "Can't click and hold with thumb while dragging with another finger.". I have a MacBook 5,3; on Karmic I have this problem and in the Lucid alpha the pointer jumps around so much in the live CD (even when I'm not touching the trackpad) that I couldn't do an install.

[John Ferlito (johnf-inodes)]

Not sure if it is related. Let me know if I should file another bug.

I have the bcm5974-dkms module installed but it doesn't work at bootup. I find that I have to rmmod bcm5974; modprobe bcm5974 to get it to work.

This is on lucid with the mactel PPA