GNOME and the future of hardware enablement

At GUADEC 2015 in Gothenburg, Sweden, Bastien Nocera related his recent personal experience getting Linux running on a cheap Windows tablet. Along the way, he challenged the GNOME project with a vision for how working with new hardware devices could go, a few GNOME releases down the line. The goal he described is one in which developing software for an arbitrary new hardware device is as simple with a GNOME desktop as it is for Android developers already.

The first half of Nocera's talk was presented as a case study of how he got Linux and GNOME to run on a generic hardware device. At the end, however, he backed up and retold the sequence of events as they had "really happened" (which was somewhat less successful). But the more optimistic version of events, he argued, was entirely within reach—if a few changes can be made to GNOME.

The hardware tale started when Nocera bought an inexpensive "iPad knock-off" tablet built by a Chinese manufacturer and decided to install GNOME in place of Windows 8, which came pre-installed. The biggest hurdle was getting the WiFi driver to work. The tablet used a Realtek chip and he was able to get a "code drop" driver from the company—but that driver was in remarkably poor shape.

It probably worked on Android, he said, but it did not with a mainline kernel. Digging into the source, he found that it was filled with useless code: tests, code targeting numerous pre-production hardware revisions, and so on. Since the WiFi module was connected to the motherboard over USB internally, the driver included all sorts of generic USB code that was unneeded for the tablet. Eventually, he and a few other hackers cut out all of the excess code—reducing the size of the driver by a factor of 20.

They then proceeded to figure out how to patch it to work on a current, standard kernel. That effort took time, but it worked in the end and he posted the driver on GitHub and began looking at what else the tablet required. He next got USB On The Go (USB OTG) running on the device's USB controller, and connected the tablet to his computer with a USB cable. That allowed him to use the Android Debug Bridge (adb) tool to catch system hangs early on in the boot process. He patched the adb daemon (adbd) to run on glibc and systemd (rather than Android's C library and init system) and posted that work on GitHub as well.

From there—he said—he set out to get EFI mixed mode working on the tablet's motherboard, so that he could boot a 64-bit kernel. After that, he replaced the tablet's bootloader with GRUB, set up Secure Boot shim, and ran the Fedora installer to install a complete, 64-bit Linux operating system. The adb tool allows developers to sideload packages onto the tablet, so, with a GNOME-supporting adbd on the device, developers could create xdg-app application bundles using GNOME Builder on their machine and upload them over the USB cable to the tablet and test them immediately. There would be no need to run emulators, simulate touchscreen and gesture events, or employ other such workarounds that are common today.

As Nocera quickly revealed, however, the last half of that story has not actually happened—at least, not yet. He has successfully gotten the WiFi driver running—with valuable help from Larry Finger. And the work on adbd and EFI mixed mode is real—although not all of the patches are ready for upstream.

The vision his story describes is what he hopes to see GNOME capable of in the near-term future, though, and that is what he most wanted to discuss. The pieces are falling into place: xdg-app is capable of producing "install anywhere" packages that, like Android .apk files, a developer could install and test with ease. Builder could make generating xdg-app packages part of its default feature set, and it could be made to integrate with adb.

There are other challenges as well, he said, some of which are not entirely in GNOME's hands. Windows 8 does not support USB OTG, for example, so even if the system-on-chip used in the tablet you buy supports USB OTG, the manufacturer may not have wired it up on the motherboard. One alternative would be USB host-to-host cables; they are cheap, but they will require some work to get running reliably on Linux desktops. Inside the connectors, most of them use cheap USB network adapters, and place a miniature Ethernet hub somewhere in between, so supporting them requires writing the appropriate device drivers.

A potentially bigger challenge is that EFI mixed mode support is not ready yet. In practice, at least, one can usually boot a 64-bit operating system on 32-bit EFI, but frequently things start to break when 64-bit drivers try to access EFI shortly after boot. Nocera also acknowledged that "cheap devices" change rather frequently, so keeping up with whatever is currently manufactured in China can be difficult. But in general, he said, if it can run a slightly older version of Windows, it can run a modern Linux distribution, too.

Nocera ended his session by declaring: "No refunds. I'm very sorry that I lied to you in the first part of the talk. We still need to do a lot of work." But, he added, developing support for the kind of plug-and-play development that he described is important for GNOME's outreach. Mobile devices are here to stay, and Android has a compelling "developer story" wherein anyone can hook up a USB cable and start writing software that they can test and run on a tablet or phone. GNOME could offer the same experience, if it sets out to do so.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2015.]