Archive

Archive for March, 2013

Ubuntu may switch to Android technologies to keep the Linux desktop competitive

March 3, 2013 37 comments

With the recent introduction of Ubuntu Touch a very interesting change of strategy is emerging for Canonical.

As Phoronix and others have discovered, Ubuntu Phone and Touch are using SurfaceFlinger as their compositor. SurfaceFlinger uses OpenGL ES to render applications screens/windows in a hardware accelerated way using the OpenGL driver of the GPU directly.

Now, Canonical is promising a completely integrated experience for Ubuntu 14.04 which will run Phone, Touch, TV and Desktop applications in one common GUI environment. How will they be able to fulfill their promise for Linux desktop applications currently running on Xorg?

So far, everyone has believed that the Ubuntu desktop is migrating from Xorg to Wayland. This migration has been going so slow that there is actually no visible sign of happening any time soon. It seems that Canonical has slightly changed the “to” part of their migration plans. They are not moving to Wayland, they are moving to SurfaceFlinger.

I, for one, think that this is a brilliant idea.

Compared to Android’s SurfaceFlinger, Wayland has not much appeal from the “possible benefits” point of view. SurfaceFlinger is developed by Google and is already deployed on countless Android devices. It has a sizable amount of developers working on it and its future is certain as long as Android is with us (which is pretty likely given its current market share and trends). Migration to Wayland hasn’t started in earnest so there would not be much effort thrown out of the window.

With the recent merging of the Android and the mainline Linux kernels, porting Linux desktops to Android hardware has already become somewhat easier. Wifi, Bluetooth and other hardware components can be accessed through the Android kernel released by the producer of the SOC/board. The biggest remaining problems are making Xorg and audio working. Xorg is used by all desktop applications while audio is used by only some (media players, screen-capture apps…etc). Xorg seems to be a fairly big problem because Android hw producers usually don’t provide X drivers at all and that makes the porting effort a show-stopper for hardware which otherwise run Android very well.

An Ubuntu desktop running on SurfaceFlinger would be a much easier subject for porting to common Android hardware compared to the current situation (as the quickly growing number of devices supporting Ubuntu Touch demonstrates this spectacularly). OpenGL ES driver comes with the Android kernel, released by the hw manufacturer, so SurfaceFlinger works right-away.

The most important part of the migration to Wayland has been the GTK and Qt backend implementations. These can also be created relatively quickly for SurfaceFlinger so 90% of the standard Linux apps would display on it right away (Qt may already has Android/SurfaceFlinger support based on their Git repository)

OK, but SurfaceFlinger is only one part of the problem, what about the rest?

It is very much possible that Canonical/Ubuntu is planning to migrate heavily to Android backend services (not only SurfaceFlinger) in order to take advantage of the huge popularity of Android among the hardware manufacturers.

Possibly, a wrapper may be created for the PulseAudio API to execute sound services with AudioFlinger. The opposite was deemed possible by one of the developers of PulseAudio, so it is certainly an option. This would make the typical audio-using Linux desktop application work on top of Android’s AudioFlinger on a stock Android kernel released by the SOC/board manufacturer.

Other Android services may also be targeted in a similar way. Hardware accelerated video playing would be a notable example but acceleration sensor, camera and GPS services would also become easy accessible for traditional Linux applications.

With such a services-migration completed, one could do a mostly complete Ubuntu port in a matter of days to Android hardware and the required skills would be way-fewer than they are now. As a result, Ubuntu would be available for almost every hardware which supports Android. Some of the ports would be done by Canonical (Nexus devices) and most of them by the community (with the Cyanogen community doing the heavy lifting in many cases).

I think this is a good strategy since it brings Linux desktop applications to commodity Android hardware. Personally, I don’t care what backend services allow my applications to run as long as they do it efficiently and without (many) bugs.

Closing the gap between Android technologies and the Linux desktop would allow the latter to stay competitive and make an integrated experience possible. Linux desktops would eventually become capable of running Android applications (Dalvik would be just another Java-like VM, next to OpenJDK and Snoracle Java) Also, Linux desktop applications may become able to run on Android as first-class citizens (by packaging the necessary wrapper libraries to SurfaceFlinger and others).

Why do I think this is a necessity?

It is widely rumored that the next major version of Android will introduce some kind of desktop environment for keyboard/mouse work. This would allow Android to start shipping on desktop PCs. Given the weight of Google, I imagine that PC vendors would immediately start selling x86/PC hardware with Android. They already do it with ChromeOS which is much more limited than Android, so a desktop-toting Android version would easily beat that in functionality (huge number of apps and an ecosystem rapidly growing up to the weight that of Windows).

In an environment like that, desktop Linux would rapidly loose its remaining competitive advantage and very soon the desktop would be dominated by Android alone (only in the Linux camp, not meaning Windows, although I think that it would eventually become a strong Windows-competitor). If desktop Linux is as easy to port to any hardware as Android and runs Android apps next to traditional Linux apps, the competitive advantage remains.

It is way too early to tell if the above is the plan of Canonical but using SurfaceFlinger points to this direction. I would definitely like to see Ubuntu and other desktop Linuxes on every possible Android devices.

UPDATE:

Soon after the article had been published, Canonical announced the development of their own compositor (Mir) and declared SurfaceFlinger as a component to be removed from the Ubuntu phablet stack. This mostly invalidates the assumption on their strategy. If Mir will be able to work with binary OpenGL ES drivers of GPU producers, that will probably make Ubuntu easier to port but definitely not as easy as an OS heavily based on Android technologies.