A guest post from Thomas Voss’ blog. Thomas is the Technical Architect (Client) at Canonical:
Some time ago, Canonical started internal discussions about our convergence strategy, clearly spelling out the distant target of shaping and developing a single computing platform and operating system that is able to power the cloud, classic desktop machines, laptops, TV sets, phones and tablets (fridges anyone?). More to this, we stated that we want a single mobile device, a bundle of portable computing power together with the respective operating system, that seamlessly adapts to different form-factors and use-cases. Or to put it a little more catchy:
Your phone is your TV, is your desktop, is your … you name it.
And yes, we were aiming for the moon. We worked hard to draft a system that would allow us to reach the moon, while at the same time catering towards our other central goal of providing a beautiful and lean user experience. It became apparent in conversations and discussions that one of the cornerstones of the future system we were designing will be the graphics stack, including the Unity shell. After much discussions about existing solutions (X & Weston), and how we could leverage them, we took a step back and distilled down our (technical) requirements for a future graphics stack:
- Tailored towards an EGL/GL(ES) world.
- Minimal assumptions regarding the underlying driver model.
- Ability to leverage existing drivers implementing the Android driver model.
- Ability to leverage existing hardware compositors.
- Efficient, in terms of memory-, CPU- and GPU-consumption/usage.
- Tightly integrated with the Unity shell, fulfilling the shell’s requirements while at the same time not dictating any sort of semantics up the stack.
- An efficient and secure input subsystem supporting demanding mobile use-cases.
- Fully tested from the ground up.
- Adaptable to future requirements.
With these priorities in mind, we revisited and carefully evaluated existing solutions again and found that neither of them satisfies our requirements. In particular, X and its driver model is way too complicated and feature-laden, resulting in a less efficient system and a driver model that is unlikely to be widely supported on mobile platforms. In the case of Weston, the lack of a clearly defined driver model as well as the lack of a rigorous development process in terms of testing driven by a set of well-defined requirements gave us doubts whether it would help us to reach the “moon”. We looked further and found Google’s SurfaceFlinger, a standalone compositor that fulfilled some but not all of our requirements. It benefits from its consistent driver model that is widely adopted and supported within the industry and it fulfills a clear set of requirements. It’s rock-solid and stable, but we did not think that it would empower us to fulfill our mission of a tightly integrated user experience that scales across form-factors. However, SurfaceFlinger was chosen as our initial solution for getting started with the overall Ubuntu Touch project, planning to replace SurfaceFlinger with Mir as soon as possible.
In summary, our evaluation of existing solutions led us to the conclusion that neither of them fits our requirements and that adjusting/adapting them would require substantial efforts, too. For this, we decided to go for our own solution, catering directly towards our goals and our vision, effectively saying: Yes, we are going to do our own display server.
The project was born and we decided to name it Mir (as in the space station), as it would be our outpost that finally enables us to reach our goal of arriving at the moon, providing a seamless and beautiful user experience spanning multiple form-factors. The team set off to work on Mir while large parts of Canonical started working on the Ubuntu Touch project (relying on SurfaceFlinger). A lot of knowledge and experience was and is transferred from the Ubuntu Touch project to the Mir team, with the work on the phone and tablet revealing more and more technical requirements and subtleties that heavily influenced the Mir architecture and implementation. Thus, one of the earliest technical decisions that has been taken by the team concerned the protocol that applications rely upon to communicate to Mir. We evaluated Wayland and compared it to the SurfaceFlinger approach, realizing that neither of them fits our needs. Wayland is a very promising and sensible attempt at standardizing the way that applications talk to a display server, however, it exposes privileged sections like the shell integration that we planned to handle differently, both for security reasons and as we wanted to decouple the way the shell works on top of the display server from the application-facing protocol. In the end, we decided to implement Mir’s core in a protocol-agnostic way, considering the communication protocol a very important part of the overall story, but not the driving one. We have chosen Google’s protocol buffers as our data and interface description language (DDL & IDL) and implemented a lean RPC layer that abstract away transport-specific details (relying on an ordinary socket by default). It is well tested and the protobuf IDL and DDL provide us with forward- as well as backward-versioning capabilities. However, the communication component of the overall system is adaptable and can be adjusted to account for future requirements and developments.
A final word on timelines: At the time of this writing, we are preparing to deploy the next version of the Unity shell tightly integrated with Mir in the not-too-distant future on the phone and the tablet. However, regarding the desktop use-case: We have integrated X, leveraging the prior XWayland work, to run on top of Mir (XMir) and started initial porting efforts for toolkits with a focus on Qt5. With our X-integration in place, you can run Mir on your desktop machine if your system runs a GPU that supports the free driver stack. For the closed-source desktop drivers: We are in active conversations with GPU vendors to enable Mir on those drivers/GPUs, too. More to this, we are working towards a more unified driver model sitting on top of EGL.
As we are moving along with the development of Mir, we will work on integrating existing toolkits with the new display stack to allow application developers a seamless transition between different form-factors and prevent them from the burden of supporting multiple different display servers. As noted before, Qt5 is our first target here, with GTK3 and XUL being in the pipeline. To support legacy X applications that cannot be adjusted to work against Mir, we will provide a translation-layer that leverages the existing XMir implementation and allows legacy X apps to use Mir transparently.
And that’s pretty much it. Thanks for reading. I hope I could give you some insight into the history of Mir, its motivation and its trajectory. If you want to dive even further into the Mir world, head over to wiki.ubuntu.com/MirSpec. A lot of work has already been done, but more of it lies ahead of us. So if you are curious, have questions, want to help us or simply want to get to know the team, join the Mir sessions at the upcoming virtual UDS. You might also want to read Olli’s description of the bigger picture, including our overall convergence strategy for Unity.
To the moon,
Thomas
March 4th, 2013 at 21:56:15 GMT+0000
So let me get this straight. You’re going to first use SurfaceFlinger, only to switch to Mir a few months later in new devices. You’re also going to use 32 bit ARM hardware, only to move to 64 bit again a few months later. And you’re probably going to use OpenGL ES 2.0 features, only to move to OpenGL ES 3.0 features a few months later.
Why can’t you just wait until 14.04, and make Ubuntu touch the “first 64 bit mobile OS” (you could and should use that for your marketing, even if it doesn’t mean that much in terms of benefits for the user). You would also get Mir from day one, and in case you need OpenGL ES 3.0 features, you can start with those from day one, too.
Why bother supporting the old stuff, when things will change pretty radically just a few months later. Just to come up with a product half a year earlier? I think it would benefit you to wait until Ubuntu touch is fully ready.
So forget about supporting Cortex A9, forget about even supporting Cortex A15 chips for Ubuntu touch. Just start with the 64 bit ones from day one. Make Ubuntu touch a 64 bit OS only, and make it support Cortex A53 for the low-end and Cortex A57 for the high-end devices (and both in big.Little mode).
That’s what you need to do, and that’s what you should do. I’m someone in the “Ubuntu touch” market. But I’d rather wait for the 14.04 version that comes with 64 bit hardware just 6 months later, instead of getting the devices you’re going to release in October.
March 5th, 2013 at 10:13:33 GMT+0000
Since you’ve said it yourself, that things are just a few months away, what’s the trouble for you to wait a bit?
Also, what is the problem for you if they’ve decided to support a wider range of devices, which mean a bigger group of users. Do you have any idea what ubuntu will be without a solid user base? You stand for the 64-bit-future-ready-genius and that’s good, because ubuntu needs it in the past, present and future. But you’re not all. And a good generic supporting layer has always been an virtue among linux world, I am not sure whether you care about it.
Last but not least, you can clearly see from the article that in their efforts based on the “legacy solutions” they’ve gained a whole of of experiences and problems which led them to further refine the architechture of Mir, isn’t that a good thing? Why don’t you like it?
Besides, changes under the hood could be radical, as you put it. But for user experience? Never. if you disagree, check vista and windows 8. Also check how Mac OS X and Rosetta handled it almost perfectly.
If you really have such a strong passion, go join the Mir project and make influence there! otherwise, applause and wait happily as you should.