FreeBSD15.0, MacBook trackpad works but not very well

Spunto the Rat Boy · Feb 11, 2026

Hello,

I've been researching this for a couple of weeks now, trying various things especially from this post Thread apple-r-trackpads-on-freebsd.83405, in an effort to get the trackpad on my early 2013 13" Retina MacBook Pro to work properly in FreeBSD 15.0-RELEASE with a GENERIC kernel. The post is very similar to my situation, but it's old enough now that things seem to have changed in the meantime. I can get the trackpad to work in a rudimentary way with the ums driver, allowing pointer movement and clicking, but nothing else: I can't tap or use two fingers for scrolling.

ums, wsp and atp are all loaded automatically, whether or not I mention them in /boot/loader.conf. By playing with kldunload and kldload I can break it so that it doesn't work at all. If put

Code:

atp_load="YES"

into /boot/loader.conf then both /dev/ums1 and /dev/atp0 are created, and the trackpad doesn't work.

I tried various ways of trying to suppress ums — module_blacklist, renaming the .ko file, disabling ums1 — in the hopes that it might allow wsp or atp to do their job, but either I didn't do it properly or it was just a bad idea.

The output from libinput debug-events is as you'd expect: when the trackpad is working, it registers movement and presses, but not taps; and when it isn't working it registers nothing from the trackpad. However, I have this line in /boot/loader.conf:

Code:

hw.usb.usbhid.enable=0

If I comment it out then the trackpad doesn't work, but I also get a new error from libinput printed in red at the top:

Code:

event5  - Apple Inc. Apple Internal Keyboard / Trackpad Touchpad: libinput bug: kernel fuzz of 40 but LIBINPUT_FUZZ_35 is missing
event5  - Apple Inc. Apple Internal Keyboard / Trackpad Touchpad: libinput bug: kernel fuzz of 27 but LIBINPUT_FUZZ_36 is missing

...that seems to be linked to udev, which is way beyond my small comfort zone, but it did make me think maybe it would work if I could solve the FUZZ issue.

I even wondered if maybe things had changed so that now ums will handle it, and I just need to configure it properly by enabling taps somewhere, which seems to be a thing with wsp and maybe atp too? But I can't find any information about that, and libinput list-devices shows all the tap settings as "n/a", I assume because the ums driver doesn't know how to deal with them.

It seems as though my trackpad is supported:
devinfo -f | grep ums

Code:

                  ums1 <Apple Inc. Apple Internal Keyboard / Trackpad, class 0/0, rev 2.00/2.24, addr 8> pnpinfo vendor=0x05ac product=0x025a devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0224 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x02 at bus=2 hubaddr=3 port=2 devaddr=8 interface=2 ugen=ugen2.8

...and 0x025a appears in usbdevs at line 1218.

Anyway, that's my main stumbling block at the moment. I've got xfce running nicely and I've even created custom keyboard layouts for vt and X11 along with my own ~/.XCompose file to get around the fact that my CTRL key is broken (or just very, very dirty). If anyone can help me fix this last thing then suddenly it becomes a machine I could consider making a daily driver, and I will be eternally grateful.

Thanks,
Ben

tOsYZYny · 2026-02-21T12:01:05+0000

The last message in the post was about sysctls, have you tried:

HexagonWin said:
So now I solved the issue. CDE works and atp works.
I basically needed to have "kern.evdev.rcpt_mask=3"
I checked it by typing "sysctl kern.evdev.rcpt_mask=3" on a booted system and atp trackpad started to work. The trackpad's quite buggy by the way. Moving weirdly and scrolling is weird, but it's still better than not working! I modified /etc/sysctl.conf and added the line to make it permanent.

In order to make the cursor move better I needed to disable the touch to click. I thus also added "hw.usb.atp.tap_minimum=2" that made it better.

Hope this post helps others like me.
Cheers.

Spunto the Rat Boy · 2026-02-21T12:58:17+0000

tOsYZYny said:
The last message in the post was about sysctls, have you tried:

Thanks for replying!

I have tried that, and also setting it to 12 which I saw elsewhere. It doesn't seem to have done any good though. But there are so many different pieces of advice floating around, it's quite possible that even though I've tried all the right things individually I just haven't tried the right combination.

I'm pretty sure I don't need to rebuild my kernel, as you did, I have all the modules you mentioned available; although hms isn't loaded by default — do you think I should stick in loader.conf?

tOsYZYny · 2026-02-21T14:08:34+0000

Before you stick it in loader.conf, you can just do kldload hms (or any module for that matter). Putting it in loader.conf just forces it to be loaded at boot time. Try loading it to see if that helps.

almostunix · 2026-02-21T14:49:12+0000

Spunto the Rat Boy said:
Hello,

I've been researching this for a couple of weeks now, trying various things especially from this post Thread apple-r-trackpads-on-freebsd.83405, in an effort to get the trackpad on my early 2013 13" Retina MacBook Pro to work properly in FreeBSD 15.0-RELEASE with a GENERIC kernel. The post is very similar to my situation, but it's old enough now that things seem to have changed in the meantime. I can get the trackpad to work in a rudimentary way with the ums driver, allowing pointer movement and clicking, but nothing else: I can't tap or use two fingers for scrolling.

ums, wsp and atp are all loaded automatically, whether or not I mention them in /boot/loader.conf. By playing with kldunload and kldload I can break it so that it doesn't work at all. If put

Code:

atp_load="YES"

into /boot/loader.conf then both /dev/ums1 and /dev/atp0 are created, and the trackpad doesn't work.

I tried various ways of trying to suppress ums — module_blacklist, renaming the .ko file, disabling ums1 — in the hopes that it might allow wsp or atp to do their job, but either I didn't do it properly or it was just a bad idea.

The output from libinput debug-events is as you'd expect: when the trackpad is working, it registers movement and presses, but not taps; and when it isn't working it registers nothing from the trackpad. However, I have this line in /boot/loader.conf:

Code:

hw.usb.usbhid.enable=0

If I comment it out then the trackpad doesn't work, but I also get a new error from libinput printed in red at the top:

Code:

event5 - Apple Inc. Apple Internal Keyboard / Trackpad Touchpad: libinput bug: kernel fuzz of 40 but LIBINPUT_FUZZ_35 is missing event5 - Apple Inc. Apple Internal Keyboard / Trackpad Touchpad: libinput bug: kernel fuzz of 27 but LIBINPUT_FUZZ_36 is missing

...that seems to be linked to udev, which is way beyond my small comfort zone, but it did make me think maybe it would work if I could solve the FUZZ issue.

I even wondered if maybe things had changed so that now ums will handle it, and I just need to configure it properly by enabling taps somewhere, which seems to be a thing with wsp and maybe atp too? But I can't find any information about that, and libinput list-devices shows all the tap settings as "n/a", I assume because the ums driver doesn't know how to deal with them.

It seems as though my trackpad is supported:
devinfo -f | grep ums

Code:

ums1 <Apple Inc. Apple Internal Keyboard / Trackpad, class 0/0, rev 2.00/2.24, addr 8> pnpinfo vendor=0x05ac product=0x025a devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0224 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x02 at bus=2 hubaddr=3 port=2 devaddr=8 interface=2 ugen=ugen2.8

...and 0x025a appears in usbdevs at line 1218.

Anyway, that's my main stumbling block at the moment. I've got xfce running nicely and I've even created custom keyboard layouts for vt and X11 along with my own ~/.XCompose file to get around the fact that my CTRL key is broken (or just very, very dirty). If anyone can help me fix this last thing then suddenly it becomes a machine I could consider making a daily driver, and I will be eternally grateful.

Thanks,
Ben

This is bare metal or in a VM? I have had to do various things to get trackpads working in a VM on Mac. And was ultimately quite successful. Haven’t tried baremetal as I heard there are still challenges with apple silicon playing nice.

Spunto the Rat Boy · 2026-02-21T16:29:36+0000

tOsYZYny said:
Before you stick it in loader.conf, you can just do kldload hms (or any module for that matter). Putting it in loader.conf just forces it to be loaded at boot time. Try loading it to see if that helps.

Well I can load it with kldload or put it in kldlist in rc.conf, but it doesn't seem to do anything that I can see. It still creates /dev/ums1 (no ums0, to my surprise).

Spunto the Rat Boy · 2026-02-21T16:35:53+0000

almostunix said:
This is bare metal or in a VM? I have had to do various things to get trackpads working in a VM on Mac. And was ultimately quite successful. Haven’t tried baremetal as I heard there are still challenges with apple silicon playing nice.

Bare metal. Interestingly I've never had any trouble at all with the trackpad in VirtualBox, or any other hardware issues. It's an Intel machine, so who knows what problems I'd be having on Apple Silicon!

And actually it's mostly pretty good. I gave up on the wi-fi card and got a dongle but other than that all the important stuff is working (for a limited definition of "important").

tOsYZYny · 2026-02-21T16:39:22+0000

almostunix said:
This is bare metal or in a VM? I have had to do various things to get trackpads working in a VM on Mac. And was ultimately quite successful. Haven’t tried baremetal as I heard there are still challenges with apple silicon playing nice.

If you need a module at boot time for the system to boot, then as I understand it must be in loader.conf. If it isn't needed until later on, then you can load it in rc.conf or manually as well via kldload. That is the only point I was trying to make. If loading it via kldload doesn't yield any change, then, that isn't the issue.

Spunto the Rat Boy · 2026-02-21T17:52:52+0000

tOsYZYny said:
If you need a module at boot time for the system to boot, then as I understand it must be in loader.conf. If it isn't needed until later on, then you can load it in rc.conf or manually as well via kldload. That is the only point I was trying to make. If loading it via kldload doesn't yield any change, then, that isn't the issue.

Yea, that's pretty much my understanding of it.

bakul · 2026-02-21T21:16:37+0000

You can disable ums loading by adding devmatch_blacklist="ums.ko" to /etc/rc.conf.