Mark Shuttleworth Declares Mir A Performance Win

[Luke_Wolf]

If a whole distro is beta testing it, that means the entire distro is switching, by default, to Wayland to "see how it goes". That's what a distro beta testing it is. Canonical is using Ubuntu to beta test Mir. They're not just letting their distro's users beta test it. They are using the distro to beta test it. Do you see the difference in those statements? If the distro is beta testing it, that means all but the most technically minded users (who also don't want to be beta testing it) are testing it too.

Red Hat has not used Fedora to beta test Wayland. Ever. They've let Fedora users beta test Wayland at their leisure. Red Hat does not care enough about Wayland to beta test it with Fedora.

English is a subtle language... what I said was very clear, but the way you chose to interpret it was in opposition to the meaning. The distro caring enough about Wayland to beta test it has nothing to do with the users caring enough about Wayland to beta test it.

I'm sorry if this post seems harsh, but you shouldn't tell anyone they're too lazy to use Google if you're too lazy to interpret their statement correctly. My statement was not ambiguous, unless you're claiming that more than 50% of Fedora users are actively using Wayland to help beta test it. In such a case as that, then the distro is beta testing it by consensus... but that's not the case. It's just a sparse collection of users who are beta testing it.

Actually it does show that Red Hat cares, because while Red Hat could have released Fedora 18 with wayland as the default with the GNOME and KDE desktops running natively on Wayland (My understanding is that both are in a state where they can be run but that it's in no way considered ready yet), but it would have given a black mark to wayland and itself as a distro, and so by not going on this before everyone (What everyone is really waiting on is the desktops not wayland) is ready and so as a result are showing that they are listening and that they care. There's no need to have a replay of KDE 4.0-4.2 with Wayland.

[coder543]

well i actually don't care if you do to be honest but at least i can say you don't understand how XMir works otherwise you won't post that assumption or try to stretch the ball to redhat park that way[especially since redhat is less related to wayland than Intel but still a good supporter and contributer]

conclusion if you don't understand ask nicely but don't go agresivelly assume things out of thin air and expect not to pass as a troll

I've spent most of my time here talking about Mir, not XMir, and Wayland, not XWayland. The only reason I was talking about Red Hat and Fedora is because Fedora is the example that was given to me, not because I chose it out of thin air. You cannot say that I don't understand XMir based on those two facts. If XMir truly is a snapshot of XWayland, then this picture (http://wayland.freedesktop.org/x-on-wayland.png) proves me correct. XMir is using Mir.

I suggest you stop assuming that anyone who doesn't attack Mir is a Mir fanboy. I also suggest that you not assume anyone who doesn't attack Wayland is a Wayland fanboy. I have attacked neither, and I am neither. You know just enough to be dangerous, but not enough to know more, based on what I've seen. I don't say this as a fact, because I don't know this, but that's the most I've been able to observe.

[jrch2k8]

See. Now I don't trust your knowledge here. Unity8 is the experimental version that runs natively on Mir. Unity7 will be running on XMir. So, I'll wait on someone else to tell me that XMir doesn't use Mir.

first "for now" [canonical trademark] seems canonical will try to push unity 8 in 13.10[was 14.04 until a week ago and 14.10 before that]

second the problem is define "use", i mean XMir uses Mir in a sense but not in another, lets break it a bit

1.) Mir surface manager: yes it is partially used since this handle coordinates, surfaces and up to some point colorspace in the framebuffer
2.) Mir compositor: partially used to compose the output of the XServer, still XServer do the heavy lifting
3.) Mir render process and GPU accel: is not used since the apps render to X11 and Xserver just use server side buffers and pass it to the screen to be composed
4.) EGL or GLSL or effects or any other Mir capable feature is never used since the XServer do the heavy lifting
5.) well some ipc between Mir and Xmir occurs too

so yes pragmatically speaking it uses Mir but it uses it like a simple game would do with SDL, the things you will need for native Mir apps arent even needed in the code to run XMir beside the very basics i mentioned, so Xmir only proves Mir can create surfaces, move them around, read XPixmaps, composite server side buffers and swap frames[mostly apply to Xwayland beside some differences].

See Xmir/Xwayland as a virtualization for graphics or like running Xorg in virtualbox emulating hardware in software but a bit less complicated

[coder543]

Actually it does show that Red Hat cares, because while Red Hat could have released Fedora 18 with wayland as the default with the GNOME and KDE desktops running natively on Wayland (My understanding is that both are in a state where they can be run but that it's in no way considered ready yet), but it would have given a black mark to wayland and itself as a distro, and so by not going on this before everyone (What everyone is really waiting on is the desktops not wayland) is ready and so as a result are showing that they are listening and that they care. There's no need to have a replay of KDE 4.0-4.2 with Wayland.

You're misapplying my use of the word "care" in that situation. What you said is true in some ways, but that stuff wasn't applicable to the point I was making.

[jmcharron]

All this bickering over two pieces of vaporware... Face it, X.Org isn't going anywhere anytime soon...

[coder543]

Mir and Wayland are display servers, meaning they're the API which applications (directly or indirectly through Qt/Gtk) call to receive input, request resolutions, etc.. (sorry if you know this, i'm just being thorough). XMir/XWayland is a X11 extension (or patch or both, idk) which passes on X11 events to a Mir/Wayland and creates a rootless X11 environment housable under Mir/Wayland.

Much of the Mir API useful for applications isn't complete, so with Ubuntu 13.10 Mir has basically three tasks (that i'm aware of): Display management (multiple screens, resolutions, color, etc), OpenGL ES screen presentation (i think it's using OpenGL ES), and Input handling (wrapping up linux udev events). Since Mir in 13.10 is just running a full screen XMir app, I doubt the GLES code will need to be very complicated (basically just buffer swapping) and the input management should be straight forward as well (though i believe this is an area where Mir did not copy Wayland's design. could be wrong). My guess is that most of the work is being put into Display Management right now, and I've heard it's largely a copy of Waylands design.

All the Mir window management stuff is yet to be done in Unity 8, so until that is Ubuntu's default desktop you can't really claim "Mir" is receiving a ton of beta testing where Wayland is not.. especially considering Wayland is actually testing the window management features with Weston (and now Gnome/KDE) whereas Mir is still playing catch-up on the other stuff.

I will agree to this. This is all pretty correct, and the reason I say Mir is receiving the beta testing is because while this does not provide testing for the full feature coverage that will be in Mir, it begins the ball rolling. If the fundamental pieces described in your post are made solid, then that's a step towards completion. Mir is not complete enough to test the other features, so testing them would only involve saying "yep, these don't work." They'll get there eventually, or give up, but this is all they can realistically distribute for widespread testing for now.

[coder543]

All this bickering over two pieces of vaporware... Face it, X.Org isn't going anywhere anytime soon...

???? What?

1984 called... they want their X Window System back.

X is going away, and soon.

[coder543]

first "for now" [canonical trademark] seems canonical will try to push unity 8 in 13.10[was 14.04 until a week ago and 14.10 before that]

second the problem is define "use", i mean XMir uses Mir in a sense but not in another, lets break it a bit

1.) Mir surface manager: yes it is partially used since this handle coordinates, surfaces and up to some point colorspace in the framebuffer
2.) Mir compositor: partially used to compose the output of the XServer, still XServer do the heavy lifting
3.) Mir render process and GPU accel: is not used since the apps render to X11 and Xserver just use server side buffers and pass it to the screen to be composed
4.) EGL or GLSL or effects or any other Mir capable feature is never used since the XServer do the heavy lifting
5.) well some ipc between Mir and Xmir occurs too

so yes pragmatically speaking it uses Mir but it uses it like a simple game would do with SDL, the things you will need for native Mir apps arent even needed in the code to run XMir beside the very basics i mentioned, so Xmir only proves Mir can create surfaces, move them around, read XPixmaps, composite server side buffers and swap frames[mostly apply to Xwayland beside some differences].

See Xmir/Xwayland as a virtualization for graphics or like running Xorg in virtualbox emulating hardware in software but a bit less complicated

It's a little more complicated than SDL, but I take your meaning.

[jrch2k8]

It's a little more complicated than SDL, but I take your meaning.

well a bit but not much after all SDL do most of this with an abstraction layer to make it easier to code and a compositor can easily be written in GL ES to match the current state of Mir's, the bit would come as emulate input devices and surfaces for X to use <-- codingly speaking

[coder543]

well a bit but not much after all SDL do most of this with an abstraction layer to make it easier to code and a compositor can easily be written in GL ES to match the current state of Mir's, the bit would come as emulate input devices and surfaces for X to use <-- codingly speaking

You also have to deal with managing displays, whether one or many, symmetric or asymmetric. That was the "little more complicated" part I was referencing, but inputs do have to be managed as well, and surfaces were implied.