Libinput on Old MacBooks


I happened to notice that KDE Plasma 6 will drop support for the old Synaptics driver that has made my old MacBook Pros work with Linux for many years. This means libinput will be the only option. I am not a fan of libinput and it is the main reason I don’t use Wayland. To use libinput on old MacBooks, I figured out I just had to copy a single file.

While many within the *nix community argue about the technical merits of Wayland, which is designed to replace the antiquated X11, I am rather indifferent to most of the technical arguments. For me, it has boiled down to this: I have tried using Wayland and it didn’t work on any of my systems. My systems are old, but they work for my needs. For my MacBook Pros, libinput made the trackpad so erratic that it was unusable. I encountered this issue with a 2012 and a 2009 MacBook Pro, but I have read other users having the issue at least up to 2015 models. This fix should cover pretty much any Apple hardware with libinput.

Compounding problems, attempting to troubleshoot the problem was an exercise in frustration. Other users had raised the issue with the libinput/Wayland developers and basically got a “you’re holding it wrong” response. Making matters worse, the documentation is confusing. It’s the type of documentation where, if you understand it, you already know enough not to need it.

When I figured out how to actually fix my trackpad I realized it was mind-numbingly simple. Furthermore, libinput should be able to do this automatically.

Time needed: 5 minutes

Configure Libinput for Old MacBooks

  1. Copy Apple Quicks File to /etc/libinput

    Open a terminal application and type in the following:
    # cp /usr/share/libinput/50-system-apple.quirks /etc/libinput/local-overides.quirks

  2. Boot into a Wayland Session

    Right now, this means you’re probably using Gnome or KDE. With KDE, on your login screen, you’ll see a box to select Wayland or X11 in the bottom left hand corner.

  3. Log out and log back in

    That’s it! Your trackpad should now be smooth. You can now use the System Settings in either KDE or Gnome to made adjustments to speed, scrolling, etc.

That was easy. Too easy. So easy that I’m going to spend the rest of this post complaining about how this should never have confused me.

Using Other Hardware with libinput

You can check in the /usr/share/libinput/ folder and see if there’s a file for your system if it’s something different. You’ll notice if you type in sudo libinput list-devices that despite libinput can identify your hardware. So why doesn’t it automatically pair the harware with the appropriate quirks file? Who knows, but issues like these prevent me from being able to recommend Linux to many users. Anything that requires opening a terminal—even if it’s as simple as copying a file—is too much for the average user.

This is the sad state of the libinput/Wayland developers. They will pontificate to no end about the technical superiority of their solutions but don’t bother making things work out of the box. They have known about this issue for years. Yet, at the same time, they want Wayland to be the default for Linux. The default has to work out of the box.

The Perils of Bad Documentation

Another problem this issue underscores is bad documentation. If you peruse my site, you’ll notice I’m a big fan of FreeBSD (on which Wayland, with all of its Linuxisms, is even more difficult to get running). Perhaps it’s the English major in me, but what I love about FreeBSD more than anything else is the documentation. It’s clear, concise, and I can always find what I’m looking for. The libinput documentation has improved since I last tried to resolve this issue (which is why I couldn’t before), but it took a lot of digging and it wasn’t immediately clear that I was supposed to change the file name.

Worse yet, throughout all my Googling to resolve this issue, the libinput documentation didn’t show up once! Online documentation should be written with SEO in mind so that the people looking for answers can actually find them! Good documentation is naturally SEO-friendly because it relies on informative and clear headings, and clearly states the problems and solutions.

Hopefully, in the future things “just work.”


Back to Top