Mir Works On Screencasting, Parallelized Page Flipping

[dee.]

Mir and Wayland comositors work very different in that regard.
As a Mir compositor all you do is rendering buffers and telling Mir which program on which buffers and then tells Mir to put it on the screen.
As a Wayland compositor you first renders buffers, then tries to figure out which input event shall go to which program, and then tries to figure out how to tell the GPU to put this on the screen.

Mir compositors doesn't have to deal with a lot of stuff that is the same for all compositors, Wayland ones does.

Firstly, there is no such thing as "Mir compositors". There's just "Mir" which at this point is a Canonical-only project with zero interest from outside parties. Everyone else is betting on Wayland.

Secondly, Mir has to deal with exactly the same thing as any Wayland compositor. Mir has to figure out which input event goes to which program, that's no different from Wayland. There's no magic involved here.

Thirdly, Mir is closely coupled with Unity, it's designed for the purposes of Unity only and not to be a portable system that serves the needs of various use cases, unlike Wayland. Canonical doesn't make any promises to maintain any sort of stable server-side API, they have outright stated that if a competing implementation or fork of Mir appears, they will break compatibility with it - or at least, will not endeavour in any way to maintain it.

So for everyone else who is not Canonical, when there already is an alternative such as Wayland, it makes absolutely no sense to attempt to implement a Mir-based desktop environment.

[giucam]

Mir and Wayland comositors work very different in that regard.
As a Mir compositor all you do is rendering buffers and telling Mir which program on which buffers and then tells Mir to put it on the screen.
As a Wayland compositor you first renders buffers, then tries to figure out which input event shall go to which program, and then tries to figure out how to tell the GPU to put this on the screen.

That's just nonsense, what is it supposed to mean? Both Mir and wayland compositors use the underlying API to show anything onscreen, such as KMS, EGL, fbdev, whatever.

[mannerov]

Cool, where can I buy one?

Such argumentation leads to nowhere

As a Mir compositor all you do is rendering buffers and telling Mir which program on which buffers and then tells Mir to put it on the screen.
As a Wayland compositor you first renders buffers, then tries to figure out which input event shall go to which program, and then tries to figure out how to tell the GPU to put this on the screen.

Mir compositors doesn't have to deal with a lot of stuff that is the same for all compositors, Wayland ones does.

That's the point: With Wayland, instead of having the important stuffs done in something it can't control (X), the compositor has to do the job. Then it can do it the way it wants, and improve more easily over time, since it is not tied to something else. That's also one layer less.

[Pajn]

Cool, where can I buy one?

I didn't say you could. But you can install Ubuntu touch on any recent Nexus phone (and also a hole lot of other Android phones even if that's unsupported).

Firstly, there is no such thing as "Mir compositors". There's just "Mir"

Unity 8 is a Mir compositor.

Secondly, Mir has to deal with exactly the same thing as any Wayland compositor. Mir has to figure out which input event goes to which program, that's no different from Wayland. There's no magic involved here.

Mir yes, it compositors no, just as I said.

Canonical doesn't make any promises to maintain any sort of stable server-side API, they have outright stated that if a competing implementation or fork of Mir appears, they will break compatibility with it - or at least, will not endeavour in any way to maintain it.

They promise to keep a stable API, what they are not promising is to keep a stable protocol. That is a huge difference.

That's the point: With Wayland, instead of having the important stuffs done in something it can't control (X), the compositor has to do the job. Then it can do it the way it wants, and improve more easily over time, since it is not tied to something else. That's also one layer less.

It is pretty common that the currently focused window want to get the input events.
It is also pretty common that what the compositor wants to render on the screen renders on the screen.
Thus it makes sense to put such stuff in a common area.

Abstracting away stuff in several layers is done at all times to ease with development.

[TheOne]

fixed it for you, moron

People that has lack of arguments incure to childish behaviour and insults. Go back to your parents basement little child.

Try running a computer with Nvidia GPU with AMD's GPU drivers.

That makes just as much sense as trying to run RPi's backend on another platform... the RPi has some very specific video hardware that needs a specific implementation.

I would have preferred an X compatible (MESA) video driver.

Only asfar as you consider having multiple different DE's a "waste of time". Is it "waste of time" to write KDE when we already have GNOME (or the other way around)? Wayland isn't exactly "just a protocol". The compositors all use libwayland, which is a common implementation of the core protocol. Writing a compositor for Wayland isn't necessarily any more complex - maybe less in some cases - than writing a window manager for X. With Wayland, the window manager and compositor are one and the same, so when you write a window manager for your Wayland-compatible DE, the writing of a compositor isn't some "extra chore" you have to do - it's just a part of writing the window manager.

Lets see how running a gnome and kde application at the same time will be when wayland hits mainstream as how packagers will deal with the different wayland backends.

Also, all of these community implementations address slightly different needs and user bases, Wayland enables them all to do their own thing while maintaining compatibility with each other. Besides, we can compare that to what does Canonical do? "Wastes a lot of time" implementing their own protocol, which no one else is going to ever use, which is incompatible with everything else in the community.

I'm not in favor of Mir or Wayland, after analyzing the situation both wayland and mir will brake lots of applications even with the XWayland and XMir compatiblity layers. Thanks God open source drivers have matured a lot, if not things would be worst.

If you're using GNOME, the Wayland compositor comes as a part of GNOME. GNOME's Wayland compositor will be compatible with KDE's Wayland compositor, but Mir won't be compatible with either.

True, unless some one is crazy enough to write a Mir backend. Many wayland fanboys have said mir is a copy paste of wayland so according to them doing a mir backend would just be some sed -e /wayland_*/ mir_ :P

Let's face it, you've been severely misinformed. Firstly, you speak of commercial companies and their necessity in implementing Wayland compositors. Well, let me ask you - what exactly do you think Canonical is? A charity?

The point is that with technologies like old good X you already have a working system from where to start working on, while on the other hand Wayland is just a protocol with some reference system called Weston which even wayland developers discourage to use, and caused lots of confusions since developers didn't understand they had to write their own implementation from scratch.

Secondly, there are some non-commercial entities implementing their own Wayland compositors - several, in fact. How many non-commercial entities are implementing anything to do with Mir - I can't even make a direct comparison here, because there is no such thing as a "Mir-compatible compositor", and there never will be, other than Canonical's.

Again... segmentation

Thirdly, Wayland is less vaporware than Mir, seeing as Wayland is being deployed on commercial devices right now - I just held a phone running Wayland in my hands a couple of days ago. Where can I buy a device with Mir? Is there any non-test-version release of any operating system shipping Mir currently? No? Then if we talk about "vaporware", it's Mir that earns this designation better.

Well, you can download the ubuntu touch image and flash it to your phone if it has proper driver support (which one is more crossplatform?). So whats the difference?

Wayland is making good progress. Now granted, there are some problems with it - nothing is perfect, but with the collaboration of community and several commercial backers, they're nothing that can't be solved down the line. With Mir, you're placing all your eggs in one basket, and it's a basket with a history of just forgetting its eggs somewhere and never speaking of them again, so...

I remember when wayland was announced, it became famous after Mark Shuttleworth (or whatever his name is) announced it on his blog, a lot of people hated him because he was going to drop X in favor of a new shinny technology, now people hates him because he dropped Wayland in favor of Mir. Even I was excited at first when I heard of wayland, but all I see is an increase on complexity which ever way you want to look at it.

Ahh X server is a spaghetti mess lets develop a new and better technology. 20 years later... damn, we should have shipped a base implementation instead of just shipping a protocol, look all those unnecessary damn implementations out there!

Time will tell...

[dee.]

I didn't say you could. But you can install Ubuntu touch on any recent Nexus phone (and also a hole lot of other Android phones even if that's unsupported).

So it's basically at the same point as Cyanogenmod at this point.

Unity 8 is a Mir compositor.

From what I gather, Unity 8 is a shell, while Mir has a separate compositor - just like X. Haven't looked into it too deep though because frankly I don't care.

Mir yes, it compositors no, just as I said.

There aren't any compositors. Canonical's implementation is the only one.

They promise to keep a stable API, what they are not promising is to keep a stable protocol. That is a huge difference.

They "promise" lots of things... like they promised to support Wayland...

It is pretty common that the currently focused window want to get the input events.
It is also pretty common that what the compositor wants to render on the screen renders on the screen.
Thus it makes sense to put such stuff in a common area.

Right, like libwayland.

Abstracting away stuff in several layers is done at all times to ease with development.

Right, like what Wayland does.

[dee.]

I would have preferred an X compatible (MESA) video driver.

Then make one yourself. Who cares really? It's not like your RPi driver would be much use on other platforms in any case.

Lets see how running a gnome and kde application at the same time will be when wayland hits mainstream as how packagers will deal with the different wayland backends.

Do you know what "backend" means? And why exactly do you imagine packagers would have to deal with them in any way?

I'm not in favor of Mir or Wayland, after analyzing the situation both wayland and mir will brake lots of applications even with the XWayland and XMir compatiblity layers. Thanks God open source drivers have matured a lot, if not things would be worst.

There would be a lot less breakage if we had just one standard to migrate to, instead of two.

True, unless some one is crazy enough to write a Mir backend. Many wayland fanboys have said mir is a copy paste of wayland so according to them doing a mir backend would just be some sed -e /wayland_*/ mir_ :P

I think either you or whoever your "fanboys" are are confusing things. XMir is pretty much a copy-paste of XWayland, but Mir is entirely different from Wayland.

The point is that with technologies like old good X you already have a working system from where to start working on, while on the other hand Wayland is just a protocol with some reference system called Weston which even wayland developers discourage to use, and caused lots of confusions since developers didn't understand they had to write their own implementation from scratch.

Which developers were "confused"? From what I can tell, most developers on that level of the stack seem pretty well informed on how Wayland works. Unless you're refering to Canonical developers, who - at least based on their FUDish misinformation which they touted as reasons for doing Mir - have at times seemed pretty confused indeed...

Again... segmentation

Again... what are you talking about?

Well, you can download the ubuntu touch image and flash it to your phone if it has proper driver support (which one is more crossplatform?). So whats the difference?

How many people do you think are going to buy phones just to download a different OS on it? That's not a viable business model for a company attempting to make it on the mobile market...

I remember when wayland was announced, it became famous after Mark Shuttleworth (or whatever his name is) announced it on his blog, a lot of people hated him because he was going to drop X in favor of a new shinny technology, now people hates him because he dropped Wayland in favor of Mir. Even I was excited at first when I heard of wayland, but all I see is an increase on complexity which ever way you want to look at it.

Wayland is about 1/10th the size of X. By what math is that an "increase in complexity"?

Ahh X server is a spaghetti mess lets develop a new and better technology. 20 years later... damn, we should have shipped a base implementation instead of just shipping a protocol, look all those unnecessary damn implementations out there!

That's FUD and just plain wrong. There is a base implementation, libwayland.

Besides which, that whole "let's put everything in one monolithic beast" approach was already tried with X, and it wasn't good.

[Onuca_V]

Completely different worlds

First, Mir is for Ubuntu.

Second, Mir is not working just fine right now and I hope it will work fine by the end of the year (wishful thinking, maybe, let's see at the middle of the year)

Third, IF Mir works great this year, how much work would be needed for GNOME, KDE or E19 to implement Mir? Is it even viable? What if Canonical changes Mir license just because they need to?

Really, Mir can be great, for Canonical. Wayland can be great, for everyone.

[profoundWHALE]

People that has lack of arguments incure to childish behaviour and insults. Go back to your parents basement little child.

You know, this brings back an old proverb. It was something about removing a speck from someone's eye when there was a plank in their own. Not as extreme of course but still very true even here.

First, Mir is for Ubuntu.

Second, Mir is not working just fine right now and I hope it will work fine by the end of the year (wishful thinking, maybe, let's see at the middle of the year)

Third, IF Mir works great this year, how much work would be needed for GNOME, KDE or E19 to implement Mir? Is it even viable? What if Canonical changes Mir license just because they need to?

Really, Mir can be great, for Canonical. Wayland can be great, for everyone.

First, Mir is made specifically with Ubuntu and Canonical in mind, since you know, they made it.

Second, Mir is already more than fine and we've known this for quite some time. But it isn't great yet. That's why they've been holding off on it until after 14.04.

Last, it does benefit everyone. You make it sound like having more FOSS is a bad thing for everyone, or at least that it doesn't benefit everyone.

[Onuca_V]

You know, this brings back an old proverb. It was something about removing a speck from someone's eye when there was a plank in their own. Not as extreme of course but still very true even here.



First, Mir is made specifically with Ubuntu and Canonical in mind, since you know, they made it.

Second, Mir is already more than fine and we've known this for quite some time. But it isn't great yet. That's why they've been holding off on it until after 14.04.

Last, it does benefit everyone. You make it sound like having more FOSS is a bad thing for everyone, or at least that it doesn't benefit everyone.

Of course. Mir can't, anytime soon, be a replacement for X. It can be only a replacement for Ubuntu and other distros using Unity (are there any others?). If it's fine and not great, well that's a pointless discussion.

I want Mir to be great, don't get me wrong. But I think Mir can't replace X in the GNU/Linux world. So, both have a place in this ecosystem: I'm just saying is clear Mir is for Unity/Ubuntu and an alternative to X needs to be developed for everyone else. If both projects succeed even better. I did not use the word "bad" at all.