Lead Mir Developer: 'Mir More Relevant Than Wayland In Two Years'

M-Saunders writes Canonical courted plenty of controversy with it announced Mir, its home-grown display server. But why did the company choose to go it alone, and not collaborate with the Wayland project? Linux Voice has an interview with Thomas Voss, Mir's lead developer. Voss explains how Mir came into being, what it offers, and why he believes it will outlast Wayland.

Comments

Not Invented Here

[headkase]

I think the main issue Canonical has with Wayland and X is that they are Not Invented Here. Canonical has their own priorities and regardless of the technical merits vs. Wayland and others Canonical wants to be in control of the display server so they can lead it to their interests and not have to convince other parties to go their way.

Re:Not Invented Here

[bluefoxlucid]

Pretty much. "Mouthpiece for Canonical: Canonical-made System Better than Stupid Other System."

Re:Not Invented Here

[Blaskowicz]

But Wayland or an implementation has always seemed to be two years away. It's just so slow moving - drivers, distros, toolkits, DEs need to be there. I'm figuring out we can finally use it in 2016 (Ubuntu 16.04 LTS variants and derivates), 2017 for debian-stable-after-jessie.
I'm figuring Ubuntu wanted their Mir so they could control the development, QA, testing, whatever of it for the Ubuntu phones, which eventually failed to be introduced or were delayed.

Re:Not Invented Here

[spitzak]

I agree that development on Wayland is at a glacial pace. I think Mir is serving a purpose: it actually got the Wayland developers to speed up considerably. But then they slowed down over the last year, so bringing up Mir again may be a good idea.

Re:Not Invented Here

[Osgeld]

its more like wayland is Designed by committee which gives you a never ending cluster of everyone's best wishes, which is why after hearing about it since 2008 the most promising thing it can say about itself in the first sentence of their own website is

  GNOME and KDE are expected to be ported to it.

Its DOA

Site broken

[DoofusOfDeath]

It appears to be Slashdotted. Someone's got to show them how to use IIS!

Re:Site broken

[NotInHere]

from the archive.org headers (X-archive-orig-server), I can tell its cloudflare-nginx they use. What wonders me, as cloudflare prevents slashdotting??

Why?

[sexconker]

What's wrong with Wayland that Mir fixes?
What else does Mir bring to the table that would make people use it over Wayland?
What is preventing Wayland from improving over the next 2 years?

If you want people to click on, read, and discuss articles, Slashdot, you should have articles worth clicking on, reading, and discussing.

I read TFA. Nothing in it answers the questions I have, not even the answer to the same fucking question that the interviewer had.

So that’s looking at Mir in relation to X. The obvious question is comparing Mir to Wayland – so what is it that Mir does, that Wayland doesn’t?

This might sound picky, but we have to distinguish what Wayland really is. Wayland is a protocol specification which is interesting because the value proposition is somewhat difficult. You’ve got a protocol and you’ve got a reference implementation. Specifically, when we started, Weston was still a test bed and everything being developed ended up in there.

No one was buying into that; no one was saying, “Look, we’re moving this to production-level quality with a bona fide protocol layer that is frozen and stable for a specific version that caters to application authors”. If you look at the Ubuntu repository today, or in Debian, there’s Wayland-cursor-whatever, so they have extensions already. So that’s a bit different from our approach to Mir, from my perspective at least.

There was this protocol that the Wayland developers finished and back then, before we did Mir and I looked into all of this, I wrote a Wayland compositor in Go, just to get to know things.

Re:Why?

[0123456]

What's wrong with X?

Fixing old code that mostly works is boring. Must Have New Shiny!

Re:Why?

[Anonymous Coward]

The things X does well (e.g. network transparency) are really irrelevant nowadays (you can just send video instead of a render command stream, it will be better) while it's underlying design makes many things we want now (e.g. smooth UI, hotplug display devices without spending 3 hours maintaining Xorg config, composited rendering, works on limited hardware) unnecessarily difficult and complicated, which encourages the proliferation of X extensions (XRandR, AIGLX), hurts the performance of the display stack, and actually break the one thing X does well (network transparency was dropped sometime around when they added Direct Rendering Manager to try and fix the X performance issues).

Re:Why?

[Uecker]

The things X does well (e.g. network transparency) are really irrelevant nowadays (you can just send video instead of a render command stream, it will be better)

No, network transparency is much more than sending pixels. It is full integration: cut&paste, window management, client to client communication etc..

while it's underlying design makes many things we want now (e.g. smooth UI, hotplug display devices without spending 3 hours maintaining Xorg config, composited rendering, works on limited hardware) unnecessarily difficult and complicated,

I do not think this is true. The underlying design of Wayland is basically the same as X: Sending messages over a socket and some buffer sharing.

which encourages the proliferation of X extensions (XRandR, AIGLX), hurts the performance of the display stack,

Why does it hurt performance?

and actually break the one thing X does well (network transparency was dropped sometime around when they added Direct Rendering Manager to try and fix the X performance issues).

This is complete bullshit. X network transparency works perfectly fine still today. I use it every day. Yes, you cannot use direct rendering over the network. 99% of all applications do not care.

Where does all the FUD come from?

Re:Why?

[TeknoHog]

IMHO, the point of X network transparency is a no-brainer in the same way as local OpenGL acceleration. Instead of wasting bandwidth on raw bitmaps, you just send the drawing commands, whether over the network or PCIe. (It's like MIDI vs. raw audio for the keyboardists out there.) I don't know all the programming details, but I've done 3D modelling over 2 MB/s cable this way, and I can't imagine it would have worked as smoothly using raw video.

Re:Why?

[ardor]

IMHO, the point of X network transparency is a no-brainer in the same way as local OpenGL acceleration. Instead of wasting bandwidth on raw bitmaps, you just send the drawing commands, whether over the network or PCIe. (It's like MIDI vs. raw audio for the keyboardists out there.) I don't know all the programming details, but I've done 3D modelling over 2 MB/s cable this way, and I can't imagine it would have worked as smoothly using raw video.

You are talking about indirect 3D rendering, which is a fundamentally different topic. It is true that you can in theory send OpenGL command streams over a network, but in practice, this works only for certain applications, where the size of the commands is not too large, and no large assets (textures, meshes) etc. are transmitted. There's a reason why everybody wants *direct* rendering for 3D on the local machine. Forget about running games with indirect rendering, for example.

But when it comes to 2D applications, it quickly becomes obvious that the X protocol is useless nowadays, since most application draw paths, fonts etc. on their own, and X only gets to handle window-sized pixmaps. X drawing commands are almost never used anymore, except by some ancient stuff, like xterm. In that case, that fancy "X11 transparency" will end up transmitting raw bitmaps over the wire. Just use RDP, VNC etc. instead.

Re:Why?

[Uecker]

Obviously, shared memory and direct access to the hardware are not network transparent. Guess how many applications require it?

You know, this discusson is rather surreal. I run remote applications right now and you guys keep telling me it is broken. It is like sitting in an airplane and your seat neighbor claims that flying is actually impossible.

Re:Why?

[Uecker]

Hey, if you like RDP better, why don't you just use it. There are clients for X. I am not the one who wants to break your user experience. All I am asking for is that you don' please break mine, because for me X works just fine.

Re:Full Disclosure: M-Saunders works for LinuxVoic

[Anonymous Coward]

He's even the author of the linked article. When you follow the link, you see it. I think that's disclosed enough?

I still don't see what's wrong with X

[Lilith's Heart-shape]

Seriously, what's so broken about X? Is it just a pain in the ass for developers to work with?

Re:I still don't see what's wrong with X

[Ignacio]

X was great for its time. But its time was when graphics hardware was slow and software was relatively undemanding. Times have changed, "we" want better software and have faster hardware, and now the bottleneck is X itself.

Re:I still don't see what's wrong with X

[N7DR]

Seriously, what's so broken about X? Is it just a pain in the ass for developers to work with?

I taught myself X from scratch last year. I didn't find it hard at all. In fact, I found it a whole lot easier than either of the fancy modern GUI toolkits that I looked at first and tried to use to implement the project I was working on.

Out of desperation born of lack of progress over an extended period, I thought I'd take a look at X. And suddenly it became easy to get the interface to behave *exactly* the way I wanted instead in somebody else's idea of what I should want.

And the documentation was complete, correct, and easy to follow. I didn't have to keep asking people for help (often, with no resolution). In a word, both the documentation and the code for X are mature. Which I submit beats bleeding edge every time if you're trying to build something robust.

Re:I still don't see what's wrong with X

[Anonymous Coward]

Seriously, what's so broken about X? Is it just a pain in the ass for developers to work with?

If X, or more specifically the X.org implementation, had been written by Leonard Poettering every article would be followed by a gazillion comments whining about how it is a monolithic single point of failure (which had to run as root until very recently on many systems), it has terminal NIH syndrome (everything from ELF library loading to low-level graphics drivers to stippled line rendering), it "violates the UNIX philosophy" by doing multiple things (it's a remote display protocol, it's a input event multiplexer, it's a bitmap typeface renderer), it is not easily extensible (extending the core protocol is often not portable so GNOME and KDE etc overload scores of "window properties" to serve as a quasi-protocol), it's full of useless crud (for example, with modern toolkits the much-vaunted 'network transparency' usually boils down to sending pre-rendered bitmaps, as the aforementioned stippled line support is not considered sufficient) etc.

Of course, X11 was a gift stolen by Prometheus from the Unix gods. All right-thinking people know that it is obviously sacrosanct and even the suggestion that someone might someday be able to do better is a vile heresy. If you need to do something it doesn't support, why not glue another carbuncle of an extension onto the creaking superstructure and perform the required ritual goat sacrifice? Thus it ever was, thus it ever shall be.

Re:I still don't see what's wrong with X

[kenaaker]

Someone above mentions exporting a video stream to handle remote sessions. I think that's actually a strong contender for a new User Interface system, but it discusses nothing about how that actually happens.

It the GPU exports an MP4 video stream that can be delivered directly to any display (local or remote) that deals with the last connection bottleneck. It's a standard, its ubiquitous, and its implemented in hardware. The return channel for user interaction needs to be done, but that doesn't have the performance issues that the presentation does.

The other piece of the system that needs to be handled is the API for the interface to the GPU hardware. A contender for that seems to be an API tied to EGL ES (if I read the acronyms right), and there should be others. That assumes the Khronos Group is doing something useful there. How many implementations are there of EGL ES to GPU hardware drivers?

The layer in the system between the user applications and the hardware interface is the place where QT, GTK, Windows graphics api, and all the other graphics toolkits go. Those toolkits shouldn't care too much about the hardware details, just the published capabilities of the GPUs.

Just some thoughts

Re:I still don't see what's wrong with X

[mrchaotica]

It's not like 10 years ago it was enjoyable either to use a dumb terminal, and quite frankly I doubt it's improved (I think they were SUN dumb terminals connected to something I can't remember). These days you're still going to compete over resources over a extremely high latency link (relative to computer performance). Not to mention the increased use of graphical elements in the UI.

It's worse... these days we're making our dumb terminals using AJAX.

Re:I still don't see what's wrong with X

[morgauxo]

"Wayland is exactly as network-transparent as X11 is in actual use these days: not very but you can make it work. Everyone is pretty much asking X11 for a drawing canvas, drawing on it, then giving it to a compositor to display. See above comments about beautifully anti-aliased fonts."

From the perspective of a low-level programmer working on Xorg and/or Wayland this is probably true. They certainly say it enough. As a user I'm not even entirely sure what a compositor is. However, I can create an X terminal in a few minutes by just doing a bare-bones Debian install with X but no desktop manager. Then a quick rc script edit makes it automatically start X and connect to my XDMCP server. From that point on all I have to do is hit the power button and I have the illusion of being at my main desktop PC. I don't really care how X is or isn't making this happening so long as it works!

Knowing nothing about compositors, 3d or 2d APIs or the source code of Weston how the hell will I do this when Wayland has replaced X? Do I have to learn write my own compositor? I already do aplicaiton programming for a living but when these Wayland guys talk I have no idea what the hell they are going on about. What will I have to learn to make Wayland work remotely? Where would I even begin?

Or.. until the applications I want to run no longer support it I can just keep using X. But what then?

Re:I still don't see what's wrong with X

[Electricity Likes Me]

And no one uses "command stream" style network rendering, nor is it actually faster, in 2014.

The only advantage X has over networked graphics is that you can forward the socket and have the app pop up in it's own window on your machine....but you can't detach and re-attach to it, or move it locally or remotely to another machine, and the actual rendering is effectively a very unnecessarily chatty bitmap stream anyway (hence why things like x2go are such huge improvements).

Remote apps and desktop on Linux *suck* compared to something like Remote Desktop on Windows, and it's absurd.

Wayland can easily, and has been shown to, support the same type of functionality, and can do it better and faster by simply sending a normal image stream.

Re:I still don't see what's wrong with X

[0123456]

you should care when the X *developers* decide that in the long run it is unmaintainable and the number of people who actually understand how everything works are less than four.

Developers always say the code is unmaintainable and they must start from scratch.

Re:I still don't see what's wrong with X

[jbolden]

Seriously, what's so broken about X?

There are 3 situations involving applications, networking and graphics
a) Running an application on a machine sharing ram with the video card.
b) Running applications on a machine close enough to the video card that the latency between them is lowish and the bandwidth is plentiful and performance is irrelevant.
c) Running applications on a machine where either the latency is high or the bandwidth is limited
X11 does terrific for (b) in exchange for damaging (a) and (c). X11 was designed in a world where (b) is common. In today's world (b) is uncommon.

Other issues:

1. The mixing of signed and unsigned coordinates causes problems both in the protocol, where 3/4 of the coordinate space is often unrepresentable, and in the C language bindings.
2. The X protocol is asynchronous for efficiency: in general, neither the server nor clients wait for replies. But the protocol’s synchronization mechanisms are insufficient, and leave many unavoidable race conditions.
3. The X protocol attempts to be policy-free and tries not to dictate any particular style of window management. However, some desirable window manager features cannot be implemented correctly, because there are window attributes which the window manager can neither fetch nor monitor.
4. The X protocol provides visibility notification events so that clients can avoid computation of obscured window contents. However, this notification doesn’t work well for nested windows or for windows with backing store.
5. None of the several ways that an application can implement interactive mouse tracking of crosshairs, bounding boxes, etc., allow both efficiency and correctness.
6. Popping up menus and dialog boxes is slow because it requires too many round trips and generates too many events. Repainting when portions of a window become visible is often slow.
7. Exceptional conditions are poorly handled. Faulty programs can freeze the server, and clients cannot kill queued requests if the user doesn’t want to wait for the server to finish servicing them.

Re:I still don't see what's wrong with X

[Kjella]

Except that's pretty much what all AJAX web apps do, they "export the UI through some generic mechanism" to the browser so I'd say it's very common. No need for roll-outs and patches, if the server now says there should be a new button there is a new button for everyone. The issue is that I find most web apps really suck compared to native applications so locally I usually want a native, non-web application.

What I'm talking about is a native toolkit that'd make the applications you normally use locally network transparent at the application level, not the display server level. Essentially a toolkit where the UI is always living in its own thread, asynchronously to the actual application. Network transparency just means that thread happens to be living on a different machine, drawing to a different display. And you could tweak it to handle that better, but you wouldn't have to it'd sort of run remotely without modification.

For example, I made a basic calculator just as a proof of concept. Connected locally (I still used a TCP connection just to localhost, better options are available) it looked and acted entirely as a native app you could use every day. It recorded buttons pushed, sent the push events to the back-end and sent updated display text back. I hadn't made it better, but I hadn't made it worse either. The cool thing though was that now I could connect to it remotely. Same calculator popped up, my button clicks go over the network, display text came back over the network. It's a working local native app and a working network transparent remote app. At once. Without any application logic in the client, just drawing tools.

Re:I still don't see what's wrong with X

[jbolden]

Direct Rendering

X can't do direct rendering. An application buffer is distinct from a graphical buffer.

(b) is still very common and I use X over such a network every day. In fact (b) is much more common now than when X11 was designed because we have much better networks now and a good wireless network falls into this category.

It is not more common. How many people share applications across a wireless? Servers are generally over a WAN not a LAN. Even when it is a WAN there are few reasons to not just have the client render (i.e. client-server)...

But even there Wayland does not offer any advantage with its RDP: You can use RDP with X as well.

  X graphical libraries aren't designed for RDP and remote rendering. The whole approach RDP violates network transparency.

As for 1990s the problems with X are still there.

Re:Full Disclosure: M-Saunders works for LinuxVoic

[geminidomino]

Follow the link? What are you, new?

Quite

[Viol8]

Wish I had mod points. Canonical arn't really interested in Linux or unix in general other than how it can ultimately make them money. Its a means to an end and if that means dropping 30 years of experience because it doesn't quite suit them then they will.

X is far from perfect but its the unix display standard and it isn't going anywhere anytime soon. If canonical want to go their own way then they'll find their user base dropping away even further.

Re:Quite

[Mister Liberty]

Wish I had mod points!
Canonical --said it once and'll say it again-- is a PR Company. And, as with PR, it's braindead, and memory-deficient.
Remember those "100 Paper Cuts", introduced by Mr. You Know Whom?

I've seen a video but not one with proof

[dbIII]

Have you seen the videos about why X is fundamentally broken?

There's one that people link to a LOT of Daniel Stone giving an unfinished powerpoint presentation at linuxconf.au 2013 where he forgot his cable so you can't actually see his Wayland desktop. It's the one where he says X is slow and gives startup times of gedit on Gnome3 as proof! That's like saying MS Windows is slow because homemade VB crapware that needs to load a pile of stuff before it can get started is slow. He also has the joke about only three people understanding X input and many people who link to that video do not understand that it is a joke. It's the one where he makes fun of people that want to run applications older than gnome3, or who want to have shaped windows, and makes fun of the Enlightenment window manager which is a project where developers have put in a lot of time to add support for Wayland. I'm pretty sure Daniel Stone would not want that presentation held up as being an authority on the subject especially since it was still a work in progress at the time and had a few obvious errors - I'd have to watch it again before I could tell you where but hopefully I don't have to and there's a finished version somewhere.
The largest mistake I recall was "nobody uses X for sending stuff over the network anymore" which should have been changed to "nobody in the gnome3 project uses it but everyone else does".


I have not seen any other videos on the topic that come close to proof of anything. Care to link one? Even better, something in text instead of the postliterate shit of having to sit down and watch a talking head reading something out that you could read yourself in 1/10 of the time.

If you think that's a good example keep looking

[dbIII]

a guy who's forgotten more about X

Including forgetting to bring his cables, forgetting to finish writing up his presentation, forgetting to remind people that his "three people who understand ..." was a joke, forgetting that gedit needs to start up a pile of gnome3 stuff so it's a poor measure of X speed and so on. You are not seeing him at his best. There must be a video or something out there of the finished presentation. You also need to understand the context is about displays for phones, which is one reason why he is disparaging about running old applications and why there is so much "nobody does whatever" when it's really "nobody in the current gnome project does whatever even if everyone else does.

Re:link down

[MiPen]

Honestly if it works better than wayland im all for it...Diversity is what makes Linux great. Maybe Ubuntu wanted to keep it under their control to cut down on the politics and make something that they can control and make work better for Ubuntu. Having alternatives makes the world a better place and being a sheepie and following the herd helps no one. I truly hope Ubuntu do a good job. After all its another system that can be forked, played with and generally improved.