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
- 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. 🎉
Next steps
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.
Bonanzle: “The Best eBay Alternative They’ve Seen”
An incredible accolade for a site that’s still technically in beta, Ecommerce Guide just named Bonanzle “The Best eBay Alternative They’ve Seen” in four years of reviewing eBay alternatives. Pessimistic side of me says that an article this effusive is an open invitation for every Tom, Dick and Harry to quibble and point out the faults of Bonanzle (of which there are admittedly still several… we’re haven’t even officially launched yet, people), or question how Bonanzle can be called an “eBay alternative” when it doesn’t even do auctions.
That said, it’s hard to imagine this project going much better than it has so far. While I’m fully aware that the hundreds of PHP eBay lookalikes are going to slowly start nibbling at what are now Bonanzle-only features, it’s comforting to know that they’re going to have to program those features in PHP (or maybe Java).
If you haven’t already, pay a visit to Bonanzle and cast your vote that Rails is an unfair advantage.
Craigslist Buyer and Seller Paradise
Bonanzle is aiming to be the Seattle Craigslist seller paradise by offering two sweet new features:
- Item importing. Items can be imported directly from Seattle Craigslist (or any other Craigslist, for that matter) by following the link to our Seattle Craigslist offer.
- 0 red tape account setup. You can test drive what it’s like to sell on Bonanzle without even setting up an account. I don’t think it could get much more simple if we tried.
Visit the link to see what Bonanzle is all about. The more people on the site, the more fun and addictive it shall become.
What is Bonanzle?
Bonanzle is an online marketplace for buying and selling goods faster while having more fun. We also aim to create the marketplace that is the most simple, yet powerful choice around.
Is Bonanzle a real word?
It is now. And it’s a verb. Bonanzle combines the wealth and excitement inherent in Bonanza (a large pocket of valuable mineral, or a source of prosperity), and the action implicit in -le (as in babble, burble, bustle). To Bonanzle is to spend quality time at an online space buying and selling goods, and meeting people.
What’s the launch plan?
In the month of May, we get as many items as possible on the site. Hopefully more than a thousand, hopefully from eBay and Craigslist refugees that are sick of complexity/fees, and who want a more immersive experience, respectively. On June 14th, the site opens to buyers. On June 21st, the great Bonanzle Bonanza happens (where as many booths as possible have a Bonanza on the same day). Sometime thereafter, we officially launch, depending on when the site achieves consistent stability and zippiness.
I care about the environment. Does Bonanzle?
Well that’s a loaded question if ever I heard one! We run a carbon-offset surplus. At Bonanzle, our goal is to offset twice the carbon we create, so that we will actively reduce CO2 levels. And when you consider that environmental watchdog ClimateCounts.org gave both eBay and Amazon.com its lowest score for online businesses, it is pretty important that we go beyond offsetting just our own use. We know of no other online marketplace committed to offsetting double the carbon it uses. We believe this makes us the environmental leader amongst online sellers. And we feel pretty good about that. But not so good that we’re going to relegate ourselves to advertising as a foofy environmental site.
Rails Internet Explorer Integration Guide
After about nine months of blissful Firefox-only development, Bonanzle finally started down the long road to Internet Explorer-compatibility a couple months ago. Though I’ve met few web developers who like the process of supporting IE, browser statistics show that fully 50% of users are still on some version of it (IE 6 has about 30%, IE 7 around 25%), so it’s something we have to deal with. Having just about wrapped up our backporting, I thought I’d share a few observations and tips on the process.
First of all, for background, I had never really touched web development of any sort until about 9 months ago. At the beginning of the backport, we had nary opened IE to see how our site would fare in it. As you might guess, the answer was “not well.” Because Bonanzle is rife with rich Javascript, and we use CSS-based layouts, few of our 30-ish pages were IE-compatible at the start of our backport. Many of our most substantial pages could not even render in IE without spewing 10+ JS errors.
But with a couple tools and rules, the process of moving toward IE compatibility ended up becoming relatively straightforward, and even our most complex and nuanced functionality has now been coerced into IE compliance.
The most important lesson I would impart to aspiring web applications: use a Javascript library. Like all young Rails sites, we started with Prototype. Once we were ready to take the training wheels off, we started using jQuery. Our backport revealed that only about half of our handwritten JS code worked in IE without modification. Some but not all of our Prototype worked. And almost all the jQuery did.
There are plenty of pages already out on the web dedicated to the comparison of jQuery to Prototype, but suffice to say for our purposes, my relationship with Javascript was an antagonistic one until I met jQuery. Now, I almost look forward to writing JS. Being able to batch select elements using pure CSS selectors, not needing to check for nulls when accessing selectors, and being able to concisely make complex behaviors happen with concatenated method calls are all big reasons. The rich plugin architecture is an even bigger reason. There seemed to be no task too large or small for a cross-browser jQuery plugin. Some of our heavily utilized plugins included the drag and drop ui-*.js, the jqModal plugin, and the jquery delegate plugin. We also worked with a contractor who custom-wrote some jQuery plugins for us that, like all jQuery I’ve encountered, “just worked” in IE (well, after they worked in Firefox, but that’s easy to make happen with Firebug).
If you do choose to go the jQuery route in writing your site, do yourself a favor and look into the JS QueueSpring plugin — it’s discussed in the previous blog, and is ideal for binding jQuery behaviors with your DOM elements in a clean and fast-loading way.
As far as CSS goes, there is no easy way to sum up means by which to write CSS that is IE6/7 compatible. I think that for all but the most experienced web developers, it is an iterative process. What I can recommend are some tools to speed up your iterations. First of all, if you’re on Windows, you’ll need to be able to install the version of IE you don’t have (6 or 7). This is most easily done by downloading the IE virtual machines Microsoft provides on their site. These provide an out-of-the-box solution for running IE6 and IE7 side-by-side on your machine (not otherwise possible). They also come bundled with some of the best tools available for figuring out what you’re looking at in IE: the Web Developer toolbar and the Script debugger. The former is basically a wussy version of Firebug that allows you to mouse over elements and see their properties, but not modify those properties dynamically, the way Firebug allows. The latter is a fairly lame way to see what’s going on in your JS when IE encounters errors. For both IE6 and IE7, you’ll need to ensure that you allow Script Debugging, which is under Tools -> Internet Options -> Advanced.
If you’ve got a big project on your hands, you’ll probably find the Script Debugger to be too barren… from what I’ve seen, it doesn’t allow you to set breakpoints in an arbitrary file, it has no watch window, and you can’t edit code from within it. A better choice is to install Visual Studio and use that as your JS debugger. If you don’t have it, you can download a free, “text only” version of Visual Studio with Ruby in Steel. You can then uninstall the RiS if it’s not your cup of tea (though it should be), leaving Visual Studio installed.
That’s the basic framework of what we’ve used to get our site from IE crashfest to lovable huggable puppy dog. Hopefully this may start off you other intrepid cross-browser souls on your journey as well. May you be strong, and repeat after me… “only 12-20 months until IE6 is obsolete.”
Bonanzle.com
Oh yeah, and anothing thing! Have you checked out bonanzle.com lately? It’s looking like the programmer finally got some help with design…
Inflection Point
2-3 weeks. That is apparently about how long it takes to reach the productivity inflection point with AJAX/Ruby on Rails/Javascript. After spending many a day stumped on various problems that seemed like they ought to be “minor,” I found myself today refactoring our most complex controller from top to bottom, fixing a couple bugs, and having the damn thing improbably work. Cool. Maybe there’s something to this language.
In seriousness, most all of this week’s interviewees have expressed considerable curiosity in how RoR differs from the other scripting languages, and why we chose it. I don’t know that I’m entirely qualified to compare it to “other languages” since my experience in both ASP and PHP has been purely C-like procedural goop written before I had OOP experience. Though that does hint at the first difference I can confidently draw between the three languages: whereas other languages tempt you at every turn to write ugly code, RoR takes MVC architecture and unit testing into its own hands to minimize the initial time penalty for writing clean code.
The database model conventions and migrations took some getting used to, but I am growing to appreciate them more as well. There is sense and utility in having a memory version of your class that mirrors the database version of the class. And it’s convenient to be able to quickly and easily commit a class instance in memory into its database counterpart. I have never even attempted to do that in another language, but I know that last time I used ASP it wouldn’t have been easy, and I imagine that is probably still the case with them.
I’m also very fond of the gem packaging system that is used to add plugins to RoR. Even with lowly DOS, installing a new plugin for one’s site is often as easy as “gem install pluginname.”
These are amongst the more superficial differences between the languages, but some of the easier ones to describe. It feels a little bit jurassic to be debugging with a console again after having used Visual Studio debugging, but it works and you get used to it. An applicant who I asked about PHP debugging wasn’t even sure if/what PHP debuggers existed, so I can’t imagine that the situation is radically better for PHP. Though I doubt it’s worse.
So, on balance, I’m giving a thumbs up to the advantages of RoR over the other languages we could have chosen. And this is after using it but a couple weeks. I’m very much looking forward to seeing what I can get done with it once I truly learn to start think like a Ruby programmer.
Thousands of Pieces
Apologies, blog.
Clearly, there’s something of an inverse relationship working between how exciting my life and blog are at a given time.
Because while days pass without an entry on here, we are still full tilt in developing a working prototype of Bonanzle. Every day a new piece falls in place, but with what seems like thousands of pieces to assemble, a fully functioning and tested commerce site isn’t something that pops up when you turn around. Recently we have recruited an everyday web designer, and we have launched a search for another everyday web developer (hey ma, we’re on Monster!). I’m confident that if we can find the right person for this role, progress will be faster still.
Talking to Jordan today I compared the process of getting a project like this fully functional is like body building for the brain. It starts with a rush of adrenaline. Then you start getting stuff done. Every day we become stronger and smarter in the ways we get stuff done. Some days I can’t wait to get on whatever the task du jour is, some days notsomuch. But then I look behind at what we’ve done, and I realize that work accumulates and we’re on our way to building one hell of a thing. Beats watching late night TV.
The Storm
The storm of activity has begun, as we have finally found the web designer/scripter we need to finish the alpha push. Without further ado, let me introduce (ahem)…. me!
I tried to do it otherwise. The eMyth guy would surely have a cow about the entrepreneur/technician overlap, but at some point, I’ve found that the complexity of proposing deals to web designers in the relative absence of cashflow and a demonstrable user or technology base is just less efficient than getting my hands dirty in the Javascript/CSS/AJAX/Ruby/Rails/HTML. And besides, most all of the contributors to the project so far have found me, not vice versa.
But I like learning, so I’m generally enjoying the web development experience so far. Moving from console/application development to web development really does bring into focus the issue of “what satisfies you” as a developer? I speculate that most people find the greatest satisfaction when they can use their creativity to make coolest possible stuff happen on their technology platform. Web development has those overtones, but it seems to me to be just as involved “how to get your code to run on buggy browsers developed 10 years ago” as it is creative problem solving. I don’t know who finds that satisfying, but as a means to an end, that’s what this game seems to be about.
Be Wrong
I love being wrong. Actually, check that, I hate being wrong. But I love finding out how and why I am being wrong.
When considering whether to undertake a new type of challenge, my guess is that “being wrong” is a big component of what makes people hesitate. Why?
In school, we all had regular opportunities to be wrong. Every test you took, you would probably be wrong on at least 10% of the answers. And there was no subjectivity; no “this seems wrong but it could just be me.” You simply didn’t “get” the test question, or you misunderstood the homework instructions, and you had to learn what had caused your reasoning flaw.
Graduating to a professional environment, it seems like the opportunities to be bona fide “wrong” are few and far between. Those who are regularly told they are “wrong” are often people who become disgruntled and leave their job. The rest of us glide happily along, forgetting what it was like to get a “C” on the final.
But what more fundamental component of personal growth is there than learning, and what more fundamental component of learning is there than experiencing failures? If you haven’t been exceedingly wrong at least six times in the last six months, I’ll bet you’re becoming less than your potential.