Linux touchpad like a Macbook: progress and a call for help

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:

Project deliverables

  1. 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).
  2. 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.
  3. First-class palm and thumb detection/ignoring
  4. Possess a means to submit bugs and have them addressed (via Github issues)
  5. “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. 🎉

Next steps

What are the next steps on the Linux touchpad roadmap?

How I will help this move forward

  1. 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.
  2. Functional quality assurance lead. I will monitor our progress toward the “Project Deliverables,” and help coordinate QA resources during development.
  3. 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.
  4. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Linux touchpad like a Macbook: goal worth pursuing?

Following is my proposal to improve the state of Linux touchpad drivers. It’s a cause I have spent almost a year of my spare time researching in depth. The first section, below, surveys the landscape of today’s available Linux touchpad drivers. The second section (“The Journey Here“) gets into greater depth describing the current failings of available choices. The third section (“The Path Forward“) proposes my best ideas for how we might be able to realize a Linux touchpad driver with polish level matching a Macbook Pro.

A survey of today’s Linux touchpad drivers

For the last 6 months, I’ve been trying to configure a Dell Precision laptop running Arch to get the same feel as the Macbook Pros I loved until the Touchbar Era. I started with the Arch default, libinput. I gave up on it in about a week, when I determined that something as simple as controlling the two-finger scroll speed was not included in the available options. The default was about 3x faster than the comfortable speed I’ve grown to love with my Macbooks. Had I not been disuaded by scroll speed, I might’ve still abandoned ship for the lack of scroll gliding (a feature I never knew I’d been using until it was taken away), which apparently I have Strong Opinions about.

Linux being Linux, I figured that I’d have a universe of touchpad drivers to choose from, each with its own awkward UI that would be confusing and painful to use, but ultimately get the job done. What I discovered instead was all of three options: one of which I had just eliminated (libinput), one that has been abandoned by its maintainers in favor of libinput (synaptics), and a third that was also abandoned by its maintainers, with zero graphical UI left behind (mtrack).

I’m writing this blog because I appreciate the nuances of how the Macbook touchpad performs, but the Touchbar Era has taught me that it sucks to have my user experience tied to the whims of a singleminded hardware company. I want to be part of the solution to create a Linux touchpad driver that’s indistinguishable from the Macbook, and has at least a minimal UI to accommodate the most common differences in user preference. I believe this would bring Linux hardware a big step closer to owning the same panache that makes the Macbook experience special. All evidence collected to date suggests that my mission may well prove quixotic. But if other people care about this, it could get done. I posit my ideas on a path forward here. If you’ve got time and want to learn more about what informs my opinions on the best path forward, read on…

The Journey Here

After realizing libinput wasn’t going to work for me, I found this blog post, whose title seduced me (“The perfect (almost) touchpad settings on Linux”). I went on to write my own follow up blog post, after discovering that the initial blog post left much to be desired compared to the Macbook standard I longed for. When it came to scroll speed and scroll glide, mtrack performed like a champ. Graphical UI be damned, I spent minutes — eventually hours — parsing the documentation. Between the 1,001 options available, I was optimistic about my prospects to recreate my Macbook utopia. And I would’ve done it, if not for the wretched nuisance I’d come to call “Cursor Nudge.” In a nutshell, “Cursor Nudge” is the phenomenon by which the center point of your depressed thumb will glide by a few millimeters as a natural effect of transitioning from the “move cursor” position to the “depress” position. None of mtrack’s 1,001 options could conquer Cursor Nudge, and eventually I grew weary of clicking right next to my target.

Down to my final shot, I really wanted synaptics to work. Yeah, it was abandonware, but it was abandonware that had been forsaken due to its multitude of options. A multitude of options seemed to be what I needed to replicate the Macbook. Initial results were promising: Cursor Nudge was not an issue with Synaptics. In fact, for my first few days using it, I found it pretty bearable. I wouldn’t confuse it with Macbook — not without the smooth acceleration and deceleration. Not with only the slighest twinge of scroll glide. Not with the need to click in the bottom right corner to effect a right click. But it was… probably satisfactory. If not for the bugs. About once or twice a day, when I put my thumb down to click or start scrolling, my open document would jerk toward the bottom of the scrollable viewing area. I Googled it. I installed the xinput listener, captured all my tracking input into logs, and tailed the logs to look for patterns that preceded the bug. And then I wondered, “does Apple still sell the pre-Touchbar Macbook?” Turns out, in what I can only interpret as tacit admission of their wrongdoing, they do. It doesn’t have enough RAM, and much of its technology is 10 years old. But its polish level remains eons beyond what I can replicate with Linux, and I refuse to carry around a mouse.

I also emailed the maintainer of libinput (previously maintainer of Synaptics). I asked him what it would take to write a Linux touchpad driver that would approach parity with the Macbook. His take wasn’t optimistic (“unless you raise enough money to hire at least one full-time developer there’s little point”). I have to imagine this is what naturally happens to a developer that has spent large swaths of a career worrying about backwards compatibility and subtle hardware differences. It sounds like a special type of hell he’s dealing with, and I appreciate the heroics that have gone into making a variety of Linux touchpad drivers almost good enough. But, even though I did eventually cave and buy new old Macbook, I’m not resigned to the imperfections of the current Linux touchpad landscape. A friend of mine who doesn’t even work in tech pointed out to me a month ago that he was reading a random post where they linked to my first blog post pursuing a Macbook-equivalent Linux driver. Somebody besides me cares about this.

The Path Forward

Wherein it becomes apparent that the author doesn’t yet know the best solution.

I think a polished driver could only be delivered within a narrow range of parameters. It probably isn’t going to support laptops older than 3-5 years old. It isn’t going to offer 1,001 options. It may or may not be continuously supported. It may use one of the existing drivers as a starting point, even if that starting codebase isn’t “clean” or well-documented.

Could we build something that works better than existing solutions for 95% of users (= developers) for less than $100k? Probably. Do users (or companies) feel enough pain with the Linux touchpad solutions that they’d donate money (or time) to tackle an esoteric issue? That is what I need to find out.

With a sufficiently enthusiastic response to this blog (todo: define sufficient), I would volunteer my own time to spearhead the non-development aspects of a solution [1]. I could create a Kickstarter page, or help PM or QA development efforts on a driver built to mimic Macbook on the widest possible range of modern laptops. I could donate time to whatever better idea you present. But, first I need a hand to determine: does this actually matter?

Update November 2018: Been putting a lot of time into this cause lately. I’m at about 10 notes and counting so far. I should have a proper blog update to post within the next month.

 

[1] I’d rather be programming this than PMing it, but my programmer brain is currently dedicated to quantifying developer activity and counting lines of code

Linux with a Macbook Touchpad Feel, Pt 2

Update: Below are what I believe to be the best settings available to tune a Linux touchpad to feel like a Macbook Pro touchpad, but it still isn’t perfect, and a year of research had led me to believe that it can’t be perfect without bigger changes to the underlying Linux drivers. I’ve written this follow up post to explore paths forward.  Original post follows…

Since my last laptop upgrade to a Dell Precision, I have made it an ongoing project to try to match my laptop (running Arch via Antergos) touchpad to the smooth & predictable operation of a Macbook Pro. It has been a long road, but at this point I have a setup that I think compares favorably to a Macbook experience.

In my previous entry, I covered the three available options for Linux touchpads before settling on mtrack as my touchpad driver of choice. In the weeks since, I have walked back this decision due to the jittery behavior of the mtrack driver when one slides a thumb in an effort to click. I frequently found myself barely missing my click target, and that’s no way to live.

So I returned to review my three options. In spite of its halting development progress, the next best option seemed to be the Synaptics driver. The fact that it was initially included as the default drive for Arch added to its credibility.

Having opted for Synaptics, the foremost challenge became locating a single concise & authoritative source to explain all available Synaptics touchpad driver options. Read on for a link to that source. I will also share my current touchpad configuration, with annotations on the updates I made to maximize the consistency & elegance of my touching experience.

Installation

Since Synaptics is the default driver for many Linux distros (including Ubuntu and Antergos, to my knowledge), you might well be running the Synaptics driver already. The easiest way to determine is to run

cat /var/log/Xorg.0.log | grep synaptics

If you see output like the following, you’re in good shape:

[ 16885.807] (II) LoadModule: "synaptics"
[ 16885.808] (II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so
[ 16885.808] (II) Module synaptics: vendor="X.Org Foundation"
[ 16885.808] (II) Using input driver 'synaptics' for 'DLL07BF:01 06CB:7A13 Touchpad'

If not, chances are there is a configuration file for libinput or mtrack that has a lower alphanumeric file name in either /etc/X11/xorg.conf.d/, the first directory Xorg looks for touchpad config files, or /usr/share/X11/xorg.conf.d/ its secondary location. To get your laptop to choose Synpatics over other drivers, you must change the filename of your Synaptics driver config file to have a lower alphanumeric precedence than its competitors. I.e.,

bill /usr/share/X11/xorg.conf.d $ ls -l
total 16
-rw-r--r-- 1 root root  1350 Dec 25 05:03 10-quirks.conf
-rw-r--r-- 1 bill users 1935 Jan  7 11:03 30-synaptics.conf
-rw-r--r-- 1 root root   951 Dec 20 09:24 40-libinput.conf
-rw-r--r-- 1 root root  1753 Nov 18  2016 70-mtrack.conf

In my case, my Synaptics driver config file lives at /usr/share/X11/xorg.conf.d/30-synaptics.conf. The “30-” that my config file begins with is a lower number than my libinput or mtrack config files contain, so Xorg chooses to use Synaptics and ignore the other drivers.

Configuration

In my past post, I lauded mtrack for going big on configurability, noting the 50-100 different options available on differing versions of mtrack. The good news is that Synaptics has even more options available than Mtrack. The bad news is that you’re not going to find any one complete & accurate source to learn about all of the options available to you.

This page is the best you’re going to find. It’s pretty good.

After reading through the litany of options available, and experimenting in real world usage, the final Synaptics config file I settled on actually implements relatively few custom options:

Section "InputClass"
        Identifier "touchpad catchall"
        Driver "synaptics"
        MatchIsTouchpad "on"
        # Enabling tap-to-click is a perilous choice that begets needing to set up palm detection/ignoring. Since I am fine clicking my touchpad, I sidestep the issue by disabling tapping. 
        Option "TapButton1" "0"
        Option "TapButton2" "0"
        Option "TapButton3" "0"
	# Using negative values for ScrollDelta implements natural scroll, a la Macbook default. 
        Option "VertScrollDelta" "-80"
	Option "HorizScrollDelta" "-80"
        # https://wiki.archlinux.org/index.php/Touchpad_Synaptics has a very buried note about this option
	# tl;dr this defines right button to be rightmost 7% and bottommost 5%
	Option "SoftButtonAreas" "93% 0 95% 0 0 0 0 0"  
        MatchDevicePath "/dev/input/event*"
EndSection

You’ll note that this config file doesn’t setup coasting after a two-finger scroll, since Synaptics enables this by default. The -80 values for scroll delta correspond closely with the rate at which a Macbook will scroll with two fingers. The greatest difference between my Linux and Macbook config is that I have enabled a slight area at the bottom right of my touchpad to function as my right click. After several hours of usage, I’ve found this area sized such that I only end up right clicking when I make an effort to go for the bottom right corner. It’s a handy optimization that prevents me from needing to remove right click from the touchpad entirely.

On to the finer details

The previous post lamented how challenging I had found it to tweak values for the touchpad properties without restarting Lightdm (logging out and logging in again). Since then, I’ve discovered two means that allow experimenting with different touchpad values without requiring a log out/log in cycle. Both methods will allow you to precisely configure your touchpad settings without needing to log out and log back in.

The first method is via xinput, the second via synclient.

Using xinput

The greatest benefit to using xinput directly in changing touchpad settings is that it will work with either the Synaptics, libinput, or mtrack drivers. The second method I’ll outline below (synclient) only works with Synaptics.

To configure your settings using xinput, start by running xinput --list. Note which ID corresponds to your touchpad (for me, it’s ID 13), and then run xinput --list-props id. For example:

$ xinput --list-props 13
Device 'DLL07BF:01 06CB:7A13 Touchpad':
	Device Enabled (142):	1
	Coordinate Transformation Matrix (144):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	Device Accel Profile (274):	1
	Device Accel Constant Deceleration (275):	2.500000
	Device Accel Adaptive Deceleration (276):	1.000000
	Device Accel Velocity Scaling (277):	12.500000
	Synaptics Edges (282):	49, 1179, 50, 878
	Synaptics Finger (283):	25, 30, 0
	Synaptics Tap Time (284):	180
	Synaptics Tap Move (285):	67
	Synaptics Tap Durations (286):	180, 180, 100
	Synaptics ClickPad (287):	1
	Synaptics Middle Button Timeout (288):	0
	Synaptics Two-Finger Pressure (289):	282
	Synaptics Two-Finger Width (290):	7
	Synaptics Scrolling Distance (291):	-80, -80
	Synaptics Edge Scrolling (292):	0, 0, 0
	Synaptics Two-Finger Scrolling (293):	1, 0
	Synaptics Move Speed (294):	1.000000, 1.750000, 0.129955, 0.000000
	Synaptics Off (295):	0
	Synaptics Locked Drags (296):	0
	Synaptics Locked Drags Timeout (297):	5000
        ...

Each of these property values correspond to properties you’ll find in the Synaptics configuration documentation. To change a value, you would then use xinput set-prop, for example:

xinput set-prop --type=int "DLL07BF:01 06CB:7A13 Touchpad" "Synaptics Scrolling Distance" -70 -70

You’ll note the first string is the copy-pasted name of my touchpad from xinput --list, the second string is the copy-pasted name of the setting that was shown via –list-props, and all of the settings that follow are the values to be used. After running the command above, when I re-run xinput --list-props id I see Synaptics Scrolling Distance (291): -80, -80, meaning my natural scroll is about 15% faster than before.

Using synclient

One benefit unique to the the Synaptics driver is that it comes with a dedicated utility for configuring its setting values. You can see all current applied settings by invoking synclient. You’ll see something like

$ synclient
Parameter settings:
    LeftEdge                = 49
    RightEdge               = 1179
    TopEdge                 = 50
    BottomEdge              = 878
    FingerLow               = 25
    FingerHigh              = 30
    MaxTapTime              = 180
    MaxTapMove              = 67
    MaxDoubleTapTime        = 180
    SingleTapTimeout        = 180
    ClickTime               = 100
    EmulateMidButtonTime    = 0
    EmulateTwoFingerMinZ    = 282
    EmulateTwoFingerMinW    = 7
    VertScrollDelta         = -70
    HorizScrollDelta        = -70
    ...

Again, you can consult the Synaptics settings documentation to map these esoteric names into actual behavior. Setting a new value is then simply a matter of running synclient VertScrollDelta=-80

Persisting configuration changes

After you’ve tweaked your touchpad to your satisfaction, you’ll need to propagate all your settings changes back into the config file we discussed in step one. The only bit that can make this challenging is if you used synclient, the variable names used by synclient can differ significantly from those that are known to xinput when it goes to configure your touchpad upon login.

If you’re not sure how your synclient values correspond to values you would feed to the Synaptics driver config file, use the steps from the “Using xinput” section above to list all the properties for your touchpad. Here, you’ll be able to see the config setting names that xinput knows for your touchpad, as well as the values it is currently using. For example, xinput --list-props tells me that after tweaking in synclient, I set up my button regions as follows:

Synaptics Soft Button Areas (314):	1079, 0, 760, 0, 0, 0, 0, 0

I can then copy those into my config file 30-mtrack.confas follows:

Section "InputClass"
        Identifier "touchpad catchall"
        Driver "synaptics"
        MatchIsTouchpad "on"
        ...
        Option "SoftButtonAreas" "1079 0 760 0 0 0 0 0"
EndSection

After the setting values have been saved in your configuration file, they will be applied automatically upon restart/login.