The note sourced to create this blog post lives here. I’ll copy updates to the blog from that note every so often, but the note will be more updated. And the note has a couple footnotes this version doesn’t support. That aside…
It’s taken me longer than I’d hoped to craft a follow up to my viral blog post on… Linux touchpad drivers (what a weird sentence to write). I’d hoped to find 10 or 20 people who shared my belief that Linux touchpads are in a sorry state. Turns out, a niche OS with a subjective quality issue is — in this case — a topic that’s important to thousands. So much so that several commenters on the last blog indicated willingness to donate time or money to improve the plight of this beleaguered driver.
If this collective will can be harnessed, we have a golden opportunity for developers to escape the limitations imposed by modern Apple hardware. Hardware manufacturers are doing their part. There are already laptops that compare favorably against Macbook on tech specs and price. Now, we “just” need software that approximates the fit-and-finish of using a Macbook. Modern day Linux is getting very close: my most recent Linux laptop is the first I’ve ever owned where waking from sleep mode reliably works. ☕
The crux of the challenge is that we need to objectively fix a subjective problem. After spending the past year examining the challenges, here’s how I think we can do it:
Define the goal
To create a touchpad solution for Linux that serves as many users as possible, we want to be maximally objective in describing what we aim to deliver.
My first idea to be objective was to quantify how the cursor worked on OS X, and create a suite of tests we’d use to guide development. That turned out to be a misadventure, for circumstantial reasons.
My second idea is my current preferred plan forward:
1) to fork libinput (overview doc, contributor docs, source), and
2) find up to three developers dedicated to making a measurably better driver.
Why start from libinput instead of building from scratch or another driver? The following line of reasoning from Peter Hutterer (libinput maintainer), persuaded me:
Don’t start from scratch. your goal is for this to be eventually used, at which point libinput is your only option. for any other approach you’ll have to a) stick to xorg only or b) convince every wayland compositor to implement support for your driver (and that you’ll maintain that driver for the upcoming future). given that Fedora already defaults to Wayland, a) isn’t really an option and b) is not likely to happen.
In addition to its Wayland integration, libinput is already built to support Xorg via xf86-input-libinput.
Why three developers for six months? Because any more than three developers A) is unrealistic to expect B) harder to coordinate C) leaves responsibility too open-ended. Why six months? Because the Static Object’s metrics suggest that should be enough time to make a significant impact on this project [footnote describes gradual pace of progress in project]. It’s easy to imagine we could begin seeing noticeable improvements to touchpad tracking accuracy within a couple months of starting development.
I believe the most serious flaw in my plan is the subjectivity around how, specifically, the cursor should behave. Practically speaking, we won’t be able to perfectly clone Apple’s touchpad behavior. So, in place of an objectively provable target, we’ll work from a shared set of intentions:
- Linux touchpad scores on par with Macbook touchpad per mouseaccuracy.com testing. As of today, I can consistently score twice as high on macOS (average score 250 with “Hard” + “Small” options) vs Linux (average score ~100).
- Visual or terminal-based means to configure rudimentary touchpad settings. The fewest options I could imagine supporting for v1 would be: scroll speed/acceleration, scroll speed, natural scrolling toggle, hopefully support for gestures.
- First-class palm and thumb detection/ignoring
- Possess a means to submit bugs and have them addressed (via Github issues)
- “Feels like a Macbook” to greatest extent possible
We would seek to achieve these modest goals only on modern laptop hardware, eg purchased within last 2-3 years. Broader support should follow.
This project’s grand vision will be realized when its users forget it exists. 🎉
What are the next steps on the Linux touchpad roadmap?
How I will help this move forward
- Accountability updates. If this post succeeds in wrangling a couple developers to move this project forward, I commit to posting at least one public update per quarter on the status of the project.
- Functional quality assurance lead. I will monitor our progress toward the “Project Deliverables,” and help coordinate QA resources during development.
- Corporate fundraiser. Reach out to companies that would stand to benefit from sponsoring better Linux touchpad performance, provided others can point me toward the appropriate contacts.
- Information conduit. I’ve collected about 20 notes worth of information about Linux touchpad drivers over the past year. Perhaps some of these would assist new project participants trying to get up to speed?
Help I need from others to move forward
Can you help advance this cause? Here’s what we need:
- Commit to hack on the project. We need 1-3 developers who can commit to pursuing the Project Deliverables over at least 3 part-time months (preferably 6-12 months). I can coordinate matching developers skills to areas of project need. Since libinput is mostly composed of C, experience in that language will be a big plus.
- Got contacts? If anyone reading this knows the decision makers at companies who might like to support a popular project, help me out with an e-intro? If we can find a benevolent corporate ally (Microsoft? Google?), we could potentially leverage their resources to fund a full time developer for some months.
- Evaluate Chrome OS touchpad driver. See my “Tangential Opportunity to Help” memo. I consider this avenue a longshot to be the long-term solution for a Linux touchpad driver, but in the short term, it might be a viable driver for Linux users until the long-term solution is built.
- Got knowledge? I’ve become a lot more of a Linux touchpad expert than I’d ever hoped, but there are still people like Peter who know a lot more than I do about the interplay between the kernel, Wayland, and the input driver. I’d love to have contact info for a couple experienced Linux OSS-familiar devs who could accelerate my future research.
If you can help with any of these: please drop a line in the blog comments, or email bill at staticobject.com
Into a future less bound to Apple’s whims
All of the above plan is subject to change if better evidence/ideas are presented. I’m a pragmatist at heart, and the proposed plan is the most realistic path I can conceive to deliver a better Linux touchpad experience before the end of 2019. There’s low-hanging fruit to be picked. The touchpad driver most Linux users are currently utilizing (libinput) is developed part time, by a single developer (thanks Peter!).
There’s never been a broad mandate to make Linux touchpads pleasant to use. With your help driving attention to this issue, we can change that.
22 Replies to “Linux touchpad like a Macbook: progress and a call for help”
I wish you good luck so much!
Hi! Developer here. If you can find funding I am willing to help with this. I have previous experience in developing device drivers on Linux and I can commit to 3 months more or less full-time, and another 3 months or so part-time if necessary.
Hi, Developer here also, I am also willing to be involved in the works if there is significant funding and also a majority of it is allocated to me.
I’ve got 6 months of hobbyist nodeCSS experience and also I own a wired mouse which I feel will be invaluable in this task.
I don’t currently own a macbook but will buy one with my allocation of the funding, I’m also thinking about getting a new blender too, so will accept recommendations.
this project: great idea, exquisite presentation and project structure, impressive preliminary research and resources summary. This guy deserves a team of dedicated and similarly competent developers.
@ Grabber A. Money: as for your slap at the “me, me, give me money” dude above – LOL, tnx. 😉
Peter is a fantastic maintainer and libinput is very well documented, and really easy to build, understand and improve. He has made it quite modular too, in the past couple of years. He will not countenance much in the way of control panel settings; he wants logic and device tweaks in the code. This is how macos works too (some linux users compare libinput unfavourably to older drivers, but they can just tweak the code and build locally, it’s easy).
I am a convert to Thinkads & linux after using macbooks for a few year,s and now, I am really happy with libinput trackpad response on my two Thinkpads thanks to changes in libinput (some of which I helped with in small ways). It is a non-issue for me now. One of these laptops is “Windows signature edition” which means a higher spec trackpad, but how it compares to the hardware capabilities of macbooks is something I don’t know. I don’t know what problems you see with the current driver, and whether those problems are due to hardware limits.
You are correct about subjectivity and it will be a problem, unless you decide on a particular macbook and macos release, and then find some way of objectively defining its behaviour. I think this will be the hardest part of your project.
> My first idea to be objective was to quantify how the cursor worked on OS X, and create a suite of tests we’d use to guide development. That turned out to be a misadventure, for circumstantial reasons.
Can you elaborate on those reasons?
Sure – the issue was that macOS doesn’t provide sufficiently granular information about the current touchpad location. There’s a link to the macOS docs in the footnotes version of this post, but the tl; dr is that the API doesn’t offer sufficient information about the user’s touch position to be able to map that into a suite of tests (as had been my initial hope).
I’m pretty satisfied with using the mouseaccuracy.com tests as a substitute though. The bottom line is that the touchpad driver needs to be functional, and the test provides an objective means of measuring that.
I’m not a developer, but I can help in donating this project!
Why are developers wasting their time on the failed Linux experiment instead of focusing on a cohesive operating system such as Free/OpenBSD?
When BSD has above a 0.01% share on laptops maybe it will be time to reevaluate this question
> Modern day Linux is getting very close: my most recent Linux laptop is the first I’ve ever owned where waking from sleep mode reliably works.
Can you share which laptop you’ve been using?
Yep, I’ve been on a Dell Precision laptop purchased about 18 months ago running arch. Great screen and keyboard, and pretty good performance for development. Aside from the touchpad performance being what it is, my other major complaint is that the built-in speakers are jank compared to my Macbooks. It’s hard to get all the details right with a laptop.
Hi Bill, I sent you an email but just wanted to make sure you got it. Couple helpful links:
1) MacOS touchpad behavior analysis: https://gist.github.com/mdmayfield/7720a0cd1e8b84a61e1543f801dc8245
2) Libinput branch with Mac-like thumb detection: https://github.com/mdmayfield/libinput/commits/wip/advanced-thumb-detection-2
Another thing – with the Microsoft Precision Touchpad, and some libinput and Linux kernel versions, there is an issue with palm detection that finally now has some hope of being remedied.
The steps to reproduce the issue are:
1) Turn on tap-to-click
2) Move the mouse cursor to someplace where you can tell if a click is registered (e.g. inactive browser tab)
3) Lightly depress a palm (“heel” of thumb) to the touchpad
If your touchpad is like my Dell XPS 15 9550’s, then this will register as a tap-to-click… **even though you never lifted the palm off the touchpad.**
What is happening here is, in slow motion:
1) Touchpad begins to register the initial skin contact as a normal touch. Kernel reports it as a finger down.
2) Libinput registers the touch.
3) As more skin contacts the touchpad, the touchpad’s firmware “realizes” it’s a palm and clears the “Confidence” bit from the touch’s properties. https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-required-hid-top-level-collections
4) Unfortunately, older Linux kernels simply discard a non-confident touch; so here the kernel simply reports the touch to userspace as ended
5) Libinput has absolutely no way of knowing *why* the touch ended, therefore when it sees the touch end, it assumes it was a deliberate tap.
With newer kernels there is a patch called “HID: multitouch: report MT_TOOL_PALM for non-confident touches” which will hopefully resolve this.
With that patch (I haven’t had a chance to try it yet) what will hopefully happen instead is:
4) The kernel continues reporting the palm touch, but adds the information that it’s a palm via MT_TOOL_PALM
5) libinput then *knows* that the touch was a palm the whole time, and aborts/cancels the touch rather than lifts it
Thanks for this work! I recently moved back to a very high end linux laptop after using a series of macbooks for 7 years, and I was amazed at just how bad the trackpad experience was. I spent upwards of 8 hours just trying different drivers and options until i finally found a some settings that, while not great, are usable. I’m very much looking forward to your results!
Is there any way for an indivudual to donate to this project?
Probably not good enough to help but you could setup a crowdfunding site? I’d be willing to donate something 🙂
Thanks to everyone who has kindly offered to donate to this project! I did consider setting up some sort of crowd funding situation, but I’ve opted against it thus far because I haven’t been able to come up with a good plan for how money would get spent. And it’s more pressure if I have to spend other people’s money wisely.
That said, if I’m unsuccessful in raising money from corporate partners, I may reconsider and open a crowd funding channel in the coming months. It would be great if we could give a passionate developer like Matt some runway to work on this full time.
Thanks for bringing up such an important issue! I’ve had some bad experiences in the past with touchpads and Linux and would dearly like the situation to be improved. I’m been using Apple hardware again for the past few years. Now on MacBook Air because it has hardware esc key. Would much prefer the power of a MacBook Pro — but I need that esc key (also might boil in this subtropical climate here)! Would like to be able to switch to another laptop — Dell XPS 15 or Lenovo ThinkPad X1 Extreme probably — without giving up a usable touchpad experience. I wonder if it would help to narrow the focus on these typical developer laptops such as Dell XPS 13/15 and ThinkPads?
All the best in your efforts.
I’m just an enthusiast and not a programmer. I like trying out Linux flavors. I have tried Manjaro and Ubuntu. I own Asus Zenbook (WIndows 10) which has a precision touchpad and it works very well in Windows except the fact that windows animations are choppy of 3 fingers and 4 fingers. The only thing that makes me end up removing Linux every time I get on hooked on to newer release is touchpad. Terribly Disgusting. No smooth scrolling. No gestures. A touchpad which behaves like a 1980s mouse. Seriously?
And I am surprised that the community at large does not give a heck about it because most of them are developers who use desktops with a mouse and not laptop. They are completely apathetic towards this. On one hand we hear all the good stuff that linux is everywhere, kernel 5.0 is coming with so and so features, it is fast,better than windows and so on, but the community at large hasn’t figured this thing out. I imagine how does Linus Torvalds use his laptop. Blogs, youtube persuading people on using linux and its advantages but how are we going to attract a novice customer when the touchpad does not seem right. Now, fanboys wills say ‘Linux is not for noobs’. Agreed, but why then every major distro says on their website that their distro is beginner friendly and why its being projected that linux is so slick and cool to be used as a primary OS. Its not. It maybe for backend servers but just not polished enough for consumers.
Like me, many have tried to point this out in forums but most of the times response is indifferent or ignorant. I think people have learned to live with it. Plus the fact that you don’t pay for linux so why demand in the first place. Why even expect? You know what, People on reddit have actually favored their lame discreet mouse wheel type scrolling for touchpad than smooth scrolling when questioned about absence of smooth scrolling in Linux, can you believe that. It is ridiculous. It is like they are covering up the flaws of linux.
I am from India. Would love to donate to your commendable and applaud worthy initiative out of this ignorant community crowd. Let me know where i can contribute.
Probably not going to directly contribute to the driver part, but I’ve been working for a bit on learning the kwin codebase and trying to implement “analog” gestures on wayland with libinput. Something that I’d love to see in whatever driver replacement is come up with is that:
1) It directly exposes raw values for everything (exactly how far someone scrolled/deltas for a gesture)
2) Provides an interpretation library ready-made for different situations. Don’t do the scroll acceleration and kinetic scrolling in the driver, but make some library that an app can call on with a given delta and a situation to know what delta it *should* have based on a user configurable preference. Then the app decides which type of situation is appropriate, and we avoid the weird bugs that come from the driver just sending the end result of what it things should be the global response to an action.
Apologies to those more familiar with the subject if I’m talking out of my butt, and feel free to correct me on this suggestion, but from what I’ve found so far the inconsistency between different apps about whether they handle things completely their own, or have the toolkit handle curves, ends up creating a mess of weird response curves everywhere that just always feels wrong. Putting everything in the driver (like synaptics) also seems like the wrong way of doing it, just because it doesn’t allow apps with exceptional requirements to choose what behavior is most appropriate (scroll to zoom probably shouldn’t be kinetic, probably has a different “natural feeling” response curve than normal scroll.) If the app is provided with a set of user-configured responses to a set of generic circumstances, I feel as though that would be an awesome way of bringing consistency into the equation without also bringing jank.
You would get my financial support for this!