With Ubuntu Touch, (and mir/unity next) we’re foraying into a whole new world of android drivers. Given the community’s bad memories from the past about graphics, let’s clear up what’s going on, and how we’ll steer clear of the murky waters of new driver support and get rock-solid Ubuntu on mobile platforms.
Android Driver Components and their Openness
First let’s talk about openness. Driver ecosystems tend to be complex, and android is no exception. To get a driver to work on android, the gpu vendors provide:
- a kernel module
The kernel module must be GPL compatible and this part of the driver is always open. This part of the driver has the responsibility of controlling the gpu hardware, and its main responisibility is to manage the incoming command buffers and the outgoing color buffers.
- libhardware implementations from android HAL.
These libraries are the glue that takes care of some basic operations the userspace system has to do, like composite a bunch of buffers, post to the framebuffer, or get a color buffer for the graphics driver to use. These libraries (called gralloc, hwc, fb, among others) are sometimes open, and sometimes closed.
- an OpenGLES and EGL userspace library
These are the parts that program the instructions for the GPU, and they are the ‘meat and potatoes’ of what the vendors provide. Unfortunately this code is closed source, as many people already know. Just because they are closed source though doesn’t mean we don’t have some idea of what’s going on in them though. They rely on the open source parts and have been picked apart pretty well by various reverse-engineering projects (like freedreno)
All the closed parts of the driver system are used via headers that are Apache license or Khronos license. These headers are API’s that change slowly, and do so in a (relatively) non-chaotic manner controlled by Google or the Khronos groups. These APIs are very distinct from DRM/gbm/etc that we see on ‘the free stack’
The drivers are not 100% open, and its not 100% closed either. Without the closed source binaries, you can’t use the core GLES functionality that you want, but enough parts of the system are open that you can infer what big parts of the system are doing. You can also have an open source ecosystem like Mir or android built around them because we interface using open headers.
As far as openness goes, its a grey area; its acceptable to call them blob drivers though 🙂
We have a lot of bad memories about things not working. I remember fighting all the time with my compiz drivers back in the days of AIGLX and the like. Luckily when we’re working on Mir and phones, we’ve remembered all this pain and have a reasonable way that we’ll jump onto the new driver platform without any wailing or gnashing of teeth.
The biggest advantage we have with the mobile drivers is that they are based around a fixed industry API that has proven itself on hundreds of millions of devices. We’re not reinventing the wheel here! We’re not heading out on our own to invent our own HAL layer, and we do not have to brow-beat gpu vendors into supporting a new API.
With this, we pick up a lot of the goodness that comes with out-of-the box Android drivers, like great power management, performance, and stability. Mir can use android drivers as they come from the driver vendor, and we’re using them in a well-known way.
Drivers and hardware support are the foundation of a well performing, amazing computing experience. With Mir and Ubuntu Next, we’re not building our house upon sand, we’re building it upon rock!
A Sneak Peek
Here’s a sneak peek of Mir (from lp:mir). This is a demo of just mir and (essentially) the Qt client that the Ubuntu Touch interface uses; this is not using Unity Next. The device is a Nexus4 with and Adreno320 gpu.