Posted on

Native emoji support (color emojis) in arch Linux

If you’re on Arch, and you use sites with native emojis like Amplenote, you probably get pretty tired of seeing empty black boxes wherever emojis are supposed to be. However, Google isn’t especially forthcoming about the easiest path to fix that.

My experience is that what you want is the ttf-emojione package from AUR. The easiest way to install it is via the Add/Remove Software app:

If the command line is more your speed, you should be able to install it via yaourt -S ttf-emojione

After you’ve installed the package, you’ll need to log out and log in for the emojis to show in their full color glory. Here’s a test of whether your handiwork was successful: 🤔🤔🤔

Posted on

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.

Posted on

Measuring developer productivity in 2019

Until I spent the better part of 50 hours writing this guide about measuring developer productivity, I had little appreciation for how far we’ve come in the past four years. If you’re an engineering manager, there’s a growing body of data that suggests you can make a blanket increase in engineering efficacy. If you’re a great developer, you now stand to earn your due. These are exciting times to be programming.

Additional topics covered in the (admittedly a bit too epic) guide:

If you manage developers, would love to hear what you think of this effort? Is it relevant to you? Anything that could make it better?

Posted on

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

Posted on

Alternatives to Xmarks (now discontinued)

Xmarks (nee Firemarks) has been a reliable companion to address my cross-platform bookmarking needs over the past 10 years. As such, I was saddened to receive word that parent company Lastpass has chosen to discontinue Xmarks as of mid-2018. This sent me on a quest to find the best Xmarks alternative, but the first Google result I was presented (alternative.to) when searching “Xmarks alternatives” contained a spate of services that had precious little relevance to users like myself who simply want the means to save bookmarks in a cross-browser compatible extension, with as few other bells and whistles as possible.

After considerable Googling, here are the top three recommendations I’d present to other Xmarks users being forced to abandon ship:

Eversync

There’s good reason that this is the most-cited service you’ll find (alongside Xmarks) when Googling terms like “cross browser bookmarks.” It supports all the major browsers/platforms (including my current laptop, running Chromium on Arch Linux). It has been doing this long enough to have a quaint (read: “embarrassingly outdated”) little website that imputes the difficulty of building a business with via bookmarking extension.

Eversync’s web site welcomes you to the 90s

Most importantly, it’s got impeccable ratings. As of March 2018, it maintains a 4.5 star rating on the Chrome app store with about 3,000 ratings. I consider this an incredible feat, given that greater volume of ratings typically drive a product’s average toward the 3 stars.

The biggest gripe I have with Eversync is that its creators package a collection of junk like “Speed Dial.” If you’re a power user with more than 500 bookmarks, Nimbus (who appears to have purchased the extension from Everhelper at some point) will try to charge you $45/year for the extension (plus Nimbus bloat). Woe that it does cost money to maintain a web service.

Chrome sync

Ok, technically this isn’t a cross-browser solution. But if you’re like me and you only stray outside of Chrome on occasion (usually to test a page I’m developing on another browser), then the simplest way to sync bookmarks is to simply use the browser’s built-in capability. No extensions to download, no potential that you’re going to have to change managers again when software maker abandons their product.

If you choose this option, you will most likely want to visit your browser’s Settings -> Sync settings and disable the properties that you don’t want or need synced on all of your workstations:

Raindrop.io

This option “only” manages 4 stars on 300 ratings in the Chrome app store, so it’s a half-step below Eversync in terms of its user reputation. I’m including it here anyways because its home page inspires me to believe that its developers are actively working on it, and thus its functionality may be more likely to improve compared to Eversync. Further, it’s list of features including “Duplicate finder” and “Broken link finder” indicate a level of product dogfooding (creator using own product = creation of features to maximize user satisfaction) that was largely absent in Xmarks. For what it’s worth, the Pro version of Raindrop is also a few bucks cheaper than the Pro version of Eversync ($5/month for Eversync vs $3/month for Raindrop).

If anyone has firsthand experience with Raindrop, I’d be much obliged to learn your satisfaction level in the comment section below.

Posted on

Toward a Linux touchpad as smooth as Macbook Pro

Update: After continuing to use my system, I opted for the Synaptics driver instead. Learn why in my follow-up.

As a longtime Macbook Pro user, I’ve grown an insatiable appetite for exceptional hardware+software implementations of laptop functionality like suspend/wake, bluetooth, wifi, and touchpad.  If there’s anything that my past Linux laptops taught me, it’s that these functions are not automatically perfect [insert shock here]. They seem easy & perfect only when they work flawlessly, and they work flawlessly only because Apple employs large teams of experts to test & polish the hardware/software interplay on a Macbook such that it feels perfect.

Since Apple gave me and the rest of the Developer community the heave-ho with its decisions on the latest generation of Macbook Pro [1], it has been a long & harsh journey toward getting a laptop experience that feels as flawless as my Macbook Pro did. But after weeks of experimentation, I wanted to share my current touchpad setup, which feels like it is approaching the buttery smoothness of my past Macbook Pros.

Touchpad options

There are two good articles on setting up a touchpad with Linux (Arch, Antergos, Debian, Ubuntu et al). As these articles explain it, there are three touchpad drivers available on Linux: synaptics (no longer supported), libinput, and mtrack. Preferring to avoid starting with abandonware, I narrowed my search down to libinput and mtrack. The choice between these options was made easier by reading the libinput philosophy not to implement features that aren’t likely to be needed by mainstream users. In their words: “In the old synaptics driver, we added options whenever something new came up and we tried to make those options generic. This was a big mistake… we’re having none of that” Practically speaking, this means that the limit of configurability in libinput is far more limited than the 1,001 settings offered by mtrack.

This isn’t to say that mtrack is a flawless choice. This is not a driver being supported and tested by teams of users & experts. It has no visual settings panel that I’m aware of, all configuration is done via text file. And the correct version to install is initially ambiguous. The officially developed version hasn’t been advanced since 2015, so a popular fork has taken up the torch in recent years. This is why Dayne’s Medium Post recommends installing directly via git. And I recommend the same.

Installing mtrack

Here are the basics to get the latest mtrack installed on your system:

cd /tmp
git clone https://github.com/p2rkw/xf86-input-mtrack.git
cd xf86-input-mtrack
./configure --with-xorg-module-dir=/usr/lib/xorg/modules
make
sudo make install

At this point you’ll have mtrack’s driver files built/installed, but Xorg still calls the shots in enabling it vs other drivers. By default, mtrack’s xorg configuration file gets placed in /usr/shared/X11/xorg.conf.d/50-mtrack.conf, which in my case meant its precedence was lower than both synaptics (placed in /etc/X11/xorg.conf.d, which takes precedence over the /usr/shared/X11/xorg.conf.d directory) and libinput (which initially had an alphanumerically lower file name (40-libinput.conf) than 50-mtrack.conf. To fix these issues, your best bet is to move your mtrack.conf file to a location/filename with higher precedence:

sudo mv /usr/share/X11/xorg.conf.d/50-mtrack.conf /etc/X11/xorg.conf.d/10-mtrack.conf

Once you’ve done these steps, mtrack should become your default touchpad driver after restarting X server. Of course, this being Linux, there is no single answer as to most easily restart X server. These people think that you can simply run startx, but that didn’t work for me without sudo, and when I ran it with sudo, I ended up setting root permissions on a file (~/.Xauthority) that prevented me from logging in. This well-rated response thinks you can sudo restart lightdm, which did work for me (albeit with different syntax since I’m on arch), but still ended up logging me out, so my official recommendation for re-starting X server is unfortunately to log out then log back in. At that point, if you run cat /var/log/Xorg.0.log | grep mtrack you should see a series of messages that show mtrack being loaded. If you don’t, this was the best thread I found for diagnosing what input driver is actually being used. If you find anything interesting, please do post it to the comments.

Crafting the dream touchpad experience

Once you get mtrack functional, then begins the process of creating a configuration file that best approximates Macbook Pro settings.  Here is my annotated config file:

# https://github.com/p2rkw/xf86-input-mtrack
Section "InputClass"
MatchIsTouchpad "on"
Identifier      "Touchpads"
MatchDevicePath "/dev/input/event*"
Driver          "mtrack"
# Sensitivity controls how fast your cursor will move. 1 is the default
Option          "Sensitivity" "1.1"
Option          "FingerHigh" "5"
Option          "FingerLow" "5"
Option          "IgnoreThumb" "true"
Option          "ThumbRatio" "70"
Option          "ThumbSize" "25"
Option          "IgnorePalm" "true"
# This ignores tap-to-click, which causes more problems than benefit in my experience
Option          "TapButton1" "0"
Option          "TapButton2" "0"
Option          "TapButton3" "0"
# If you want a middle-click, then "ClickFinger2" should be value "2"
Option          "ClickFinger1" "1"
Option          "ClickFinger2" "1"
Option          "ClickFinger3" "3"
Option          "ButtonMoveEmulate" "true"
Option          "ButtonIntegrated" "true"
Option		"ButtonEnable" "true"
# "ButtonZonesEnable" means that your trackpad gets divided into three equal sections, where clicking any third of the touchpad sends the click code in "ClickFingerX". Since I didn't want middle-click, the left two thirds of my touchpad are left click, and the right third is right click:
Option          "ButtonZonesEnable" "true"
Option          "ClickTime" "25"
# Ensures that bottom 5% of touchpad doesn't register taps
Option          "EdgeBottomSize" "5"
Option          "SwipeLeftButton" "8"
Option          "SwipeRightButton" "9"
Option          "SwipeUpButton" "0"
Option          "SwipeDownButton" "0"
Option          "SwipeDistance" "700"
# ScrollCoast makes touchpad feel a bit more Mac-like, although it coasts in chunks and isn't relative to speed at which two finger scroll was happening
Option          "ScrollCoastDuration" "600"
Option          "ScrollCoastEnableSpeed" "0.05"
# This sets up Macbook-like natural scroll. If you want to scroll down by swiping your fingers down, reverse the "5" and the "4" here:
Option          "ScrollUpButton" "5"
Option          "ScrollDownButton" "4"
Option          "ScrollLeftButton" "7"
Option          "ScrollRightButton" "6"
# Without this option set to a high value, there are types of click+hold-and-move functionality (most easily reproed by click and then move up-right) that get ignored
Option          "Hold1Move1StationaryMaxMove" "1000"
# Smaller ScrollDistance translates to faster scrolling. ScrollDistance of 10 scrolls a long page in one swipe.
Option          "ScrollDistance" "22"
Option		"ScrollClickTime" "12"
Option		"ScrollSensitivity" "0"
EndSection

In a more perfect world, Wordpest wouldn’t have removed the indentation in that block. It is not the world in which we live.

Future improvements

Compared to the miserable touchpad experience I had endured with synaptics and libinput, it has been delightful to get reliable two-finger scrolling that coasts, and to get my two-finger scroll speed comparable to what feels normal from my time in OS X. Still on my list to try to improve the configuration as I move forward:

  • Fix the couple pixels that touchpad tends to stray when I am setting down my thumb in an attempt to click (classic Linux touchpad annoyance)
  • When beginning a new scroll action while coast is active, scroll occurs at 10x normal speed
  • Setup two-finger scrolling to work as smoothly as OS X, rather than scrolling the page in small, discrete increments
  • Determine if it’s somehow possible to restart X server without getting logged out (unlikely, given how much Googling I’ve done on this topic)

Footnotes
[1] While the touch bar is as bad for programming as numerous developers predicted, it was minuscule amount key travel inherent in their butterfly keys that served as my breaking point. Honorable mentions to the laptop hard crashing every few days, and the touchpad that is so impossibly large as to occasionally pick up spurious input (although their software integration makes that problem occur a fraction as often as it would for a comparable Linux laptop)