Jolla Ports Wayland To Android GPU Drivers 90
An anonymous reader writes "A Jolla Sailfish OS engineer has ported Wayland to run on Android GPU drivers. The implementation uses libhybis with the Android driver so that the rest of the operating system can be a conventional glibc-based Linux operating system, such as Mer / Sailfish OS. The code is to be LGPL licensed. The reported reasoning for making Wayland support Android GPU drivers was difficulty in ODM vendors not wishing to offer driver support for platforms aside from Android."
Re:Eh? (Score:5, Informative)
Jolla is a bunch of x-Nokia engineers continuing the work Nokia was doing on MeeGo. The name of their version of MeeGo is Sailfish. Wayland is a next generation display manager similar to Aqua on Mac that is currently looking to replace some of X11's functionality. Jolla ported the Android drivers over to Wayland so that Sailfish can run on GPUs designed for Android. This allows Jolla to buy off the shelf (cheap) GPUs and run Sailfish on it i.e. keep hardware parts costs down.
The use of inexpensive hardware means that Jolla is not going to be only at higher price points. They are producing a mainstream phone and there had been debate about that. This is important because we now for sure that Sailfish is going with Wayland unlike MeeGo which used a more primitive direct system.
In short
a) Wayland is cool
b) Sailfish is cool
c) Jolla is cool
So all around a classic /. news for nerds story.
Re:Eh? (Score:5, Informative)
Wayland is an alternative windowing system for *nix OSes; a counterpart to Xorg, Xfree86, X11, and pals. While the others are all based on the original X windowing system, Wayland is simply different in that respect.
The story is about successfully porting the Wayland windowing system to be able to work with android flavored GPU drivers, presumably because many SoC makers only target Android as a platform.
Why?
Suppose you want to build a custom *nix flavored tablet distro to run on these smexxy new atom and arm cpus hitting the market, and the SoC solutions look attractive. "Oh noez!" You shout in exasperation "they won't gives me duh sourcez codez! I cannuh compile native kernal driverz an shitz!"
With this hybrid mashup, this port of Wayland can use the vendor created android drivers out of the box, making the tight fisted "no, our precious can't be shared! Bad Linuxesss.. Bad!" Behavior coming from nVidia and Broadcom in respect to this issue, much less of a showstopper, and more of just a petty annoyance.
Re:Sailfish (Score:5, Informative)
Re:Eh? (Score:5, Informative)
Seriously, you had an ex girlfriend named... Wayland? Did "she" have stubble too?
Google for "Susan Wayland" sometime, when you're not at work. When you're done wanking, come back and tell me about that 'stubble' she has.
Re:The most interesting thing is left out (Score:3, Informative)
"But, I will say that their behavior has improved - they are now participating in the project, discussing, upstreaming patches that are useful. And I forgive them because they've changed their ways and are participating sanely now."
You left out that bit of the blog post.
Let's try to explain the technology (Score:5, Informative)
Phoronix article is quite low on information, and even the original post at http://mer-project.blogspot.fi/2013/04/wayland-utilizing-android-gpu-drivers.html assumes some technical knowledge of graphics stack. The basic idea is actually pretty simple. I'll try to break it down.
GPU drivers form a combination of EGL and GLESv2 libraries, each GPU vendor providing their own
This is where libhybris comes into play. The GPU driver libraries don't work without Bionic libc - so libhybris, while running on top of regular linux (and thus [e]glibc), keeps a private Bionic libc open for the GPU drivers' use, and redirects all the EGL/GLESv2 calls to the GPU driver libraries. These libraries run in their own Bionic universe, and tell the actual display hardware what to do.
The new part about Wayland support is just a logical extension of the same behaviour. Wayland already depends on EGL for buffer management, so "all" it really needs is a native display handler. Now as it happens, the native Android display structure can be mapped to the Wayland-EGL display structure. It's not trivial, but it's certainly doable. Thanks to libhybris, the Wayland libraries see a correct native display type and operate on that, while the Android GPU libraries see their respective native display type and thus can drive the hardware as ever before. After all, it's still the SAME hardware regardless of what operating system we may be running. Registers are registers and memory is still memory. From the GPU drivers' point of view nothing has changed.
So what has happened? In addition to just redirecting graphics stack calls to Android drivers, we are now also translating the display subsystem between two somewhat different systems.
If all of the above sounds eerily familiar, you are correct. In networking this kind of design is called a proxy, or if we're talking about link layer, it would be a multi-protocol label switch. Logically there's not much difference.