New Macbook Ubuntu Ready???

[woodward]

I changed the bcm5974-dkms driver so that for "clickable trackpad macbooks (pros)" the bottom 1/4 of the track pad acts like a button. The rest of the trackpad operates normally. The functionality for non-clickable trackpads remains unchanged. Tested on a Macbook Pro 5,1 running intrepid. I have attached the new bcm5974.c file, installation instructions are at the top of the file.

Cheers

[alexmurray]

I changed the bcm5974-dkms driver so that for "clickable trackpad macbooks (pros)" the bottom 1/4 of the track pad acts like a button. The rest of the trackpad operates normally. The functionality for non-clickable trackpads remains unchanged. Tested on a Macbook Pro 5,1 running intrepid. I have attached the new bcm5974.c file, installation instructions are at the top of the file.

Cheers

woodward - nice work. I've cleaned it up a bit (use linux kernel coding standards etc) and made a patch against the bcm5974-dkms package in the mactel ppa - I also changed it to be the top 4/5 instead of just 3/4 as this gives a bit more usable room for scrolling etc - see attached patch. Its very nice to be able to click and drag with 2 fingers now - do you know if its possible though to change it so that we still get mouse movement and scrolling events from the entire trackpad area (since now the bottom section only acts as a button, and hence is like a dead area for mouse movements when no button is pressed) as this would be even more like the functionality on OSX?

Great work.

[woodward]

alexmurray - Thank you.

do you know if its possible though to change it so that we still get mouse movement and scrolling events from the entire trackpad area (since now the bottom section only acts as a button, and hence is like a dead area for mouse movements when no button is pressed) as this would be even more like the functionality on OSX?

This is definitely possible. Only when a button press is detected "if(ibt)", the code would ignore fingers in the bottom 1/5th "abs_y > 4/5". But when I use a trackpad, I usually rest my thumb on the "button" and click as needed. Mac OS actually seems to allow this "resting the thumb" through some additional logic; in OS X if you rest your thumb and move the mouse around a bit, all without clicking, then move your thumb around, you see that they have actually enter a mode where the bottom 1/5th does not register mouse motion. This would take a lot more logic for us to handle properly. We probably need a survey of how people use this new trackpad in OS X.

Regardless of this new patch, there is still another problem. The usb device does not always report fingers in the order in which they were added to the pad. Which is what has been assumed in the bcm5974 code. This can result in the mouse jumping when you drop a second finger to make a right click. OS X must be remembering the location of the first finger and then making the new "first finger" the one that is closest to the old location. We need to implement something similar. This happens rarely, but is annoying when it does, especially when you are trying to do precision right-clicking.

[inphektion]

can any of you nice people get this into a jaunty package? I've been fighting to get anything working there with the touchpad.

[alexmurray]

alexmurray - Thank you.



This is definitely possible. Only when a button press is detected "if(ibt)", the code would ignore fingers in the bottom 1/5th "abs_y > 4/5". But when I use a trackpad, I usually rest my thumb on the "button" and click as needed. Mac OS actually seems to allow this "resting the thumb" through some additional logic; in OS X if you rest your thumb and move the mouse around a bit, all without clicking, then move your thumb around, you see that they have actually enter a mode where the bottom 1/5th does not register mouse motion. This would take a lot more logic for us to handle properly. We probably need a survey of how people use this new trackpad in OS X.

Regardless of this new patch, there is still another problem. The usb device does not always report fingers in the order in which they were added to the pad. Which is what has been assumed in the bcm5974 code. This can result in the mouse jumping when you drop a second finger to make a right click. OS X must be remembering the location of the first finger and then making the new "first finger" the one that is closest to the old location. We need to implement something similar. This happens rarely, but is annoying when it does, especially when you are trying to do precision right-clicking.

good points - something else that this patch changes is that now only left clicking works with the bottom 1/5th of the trackpad, two / three finger clicks get reported as just single clicks so if this could also be somehow fixed that would be awesome too.

The best way to use the patch (and I think to do more development with this driver) is to use git to make a copy of the bcm5974-dkms git repository and work with that:

To make a clone of the repo:

git clone http://bitmath.org/git/bcm5974-dkms.git

this will create a directory bcm5974-dkms which contains a clone of the git repo.

Then you can edit the driver (or apply the patch I posted above)

cd bcm5974-dkms
patch -p1 < bcm5974-4_5.patch

or

vim usr/src/dkms_source_tree/bcm5974.c
... make changes

then to compile the new version as a .deb that you can then install

[from within the bcm5974-dkms directory]
debuild -us -uc -i -I

then to install the deb (which is now sitting in the parent directory of the bcm5974-dkms directory)

sudo debi

now you can

rmmod bcm5974 && sudo modprobe bcm5974

to load your new module.

[cyberdork33]

please make patches against the kernel version and update there.

If you'd like to update the ppa, you need to join the mactel-support team in launchpad, and you will have access to the ppa to upload. Someone has to approve your membership (but if you PM with your launchpad username so that I know who you are, I will approve it).

[alexmurray]

please make patches against the kernel version and update there.

I agree that any patches should be pushed upstream, but the method I outlined above is (IMHO) the easiest way to do development against the current driver. When this work is in a stage ready to be merged back upstream, then it should be relatively easy to just push the patches against the mactel bcm5974 module back to lkml.

[woodward]

something else that this patch changes is that now only left clicking works with the bottom 1/5th of the trackpad, two / three finger clicks get reported as just single clicks so if this could also be somehow fixed that would be awesome too.

I see what you are saying. This would take some additional logic. But this isn't a way that I use the trackpad; if I want to right click, I put two fingers on the top 4/5ths and click with my thumb in the bottom 1/5th. Just my 2 cents. Cheers

[cyberdork33]

I agree that any patches should be pushed upstream, but the method I outlined above is (IMHO) the easiest way to do development against the current driver. When this work is in a stage ready to be merged back upstream, then it should be relatively easy to just push the patches against the mactel bcm5974 module back to lkml.

OK. My concern is that some of the driver code in the mactel ppa is already upstream. development work is, of course, fine to put in the PPA.

[luke-nz]

I had a problem for a long time with the new MB trackpad, which I have now resolved. I'm posting the problem and solution here for anyone with the same issue.

The only way I could get the system to recognise changes to the config in /etc/hal/fdi/policy was by removing all the input sections in xorg. I made that change and then restarted X and all was well (touch-click was disabled and two-finger right click worked). After restarting my computer, however, I discovered I could no longer login to X as it did not respond to the keyboard or the trackpad. I could still switch to a terminal (ctrl-alt-fn-f1), and once there I restarted gdm (sudo /etc/init.id/gdm restart). X now detected my keyboard/trackpad and all was well.

I've been doing that for three months, and I finally got fed up enough with it to look into it a little more. Seems gdm is usually started with a sequence number of 20, but the HAL daemon (at least on my install) is 24. I assume that means that gdm starts X before hardware information is available, and if nothing is specified in Xorg it assumes there is no keyboard.

I had success with changing the gdm sequence number to 22 at all runlevels, though 25 would possibly make more sense?

If someone more knowledgeable than me could confirm this I'd be grateful. I'm just happy the damned thing works now.