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.

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.”