Mir Developer: Anyone Interested In Native Wayland Clients In Mir?

[Pajn]

Honestly i no longer understand what the hell is Mir. Is it a protocol? Why would we need another protocol compatible with wayland? Is it trying to be a wayland-compatible display server like Xorg? I see that being useful. One thing Xorg did good is being basically the one display server that everyone used and it made things simpler. With wayland if we happen to need handling various things like hotkeys or screenshots or similar stuff on per-desktop basis it would be bad. Mir-the-server would solve that at least.

Mir is an has always been a display server that offers both and API for client (applications) to render data and an API for compositors to manage/composit all the clients.
What this post basically is saying is to add Wayland (which is a protocol for client to talk to compositors) support to Mir.
What this would allow is for you to write a Wayland compatible compositor without having to deal with all the displayservery parts like monitor configuration, rendering devices, graphic drivers and such. Similar to libweston but as an display server instead of a library and designed from the ground up to support different desktop environments instead of being an afterthought.

I'm actually starting to get concerned here. Has this really devolved into nothing more than a political discussion by people who have no idea what any of the terms involved mean?

Has it ever been any other way?

The idea of "just port Unity 8 to Wayland" is a laughably absurd notion missing any understanding of where the shell fits within the stack. Wayland is still a protocol, not another display server for things to run on top of. This would mean making Unity 8 a Wayland-compatible compositor itself, giving it at least a DRM backend and the same support for Wayland clients that we're talking about in the first place. When we're talking about Wayland, the concept of a 'window manager' or a 'desktop shell' as separable concepts is at best an implementation detail of a specific compositor and not the only requirements of such.

While I would love for the Unity 8 forks to succeed I don't think any of them will for this exact reason. It's obvious that the people who currently are talking about it does not know what they are doing.

Mir has a DRM backend as well as an X backend, it has the additional protocol to be able to handle a shell of it's own and the externalization of window management capabilities. Window management policies aren't restricted to floating windows, it also supports tiled, phone, and tablet styles of window management. You can do these things while writing drastically less code than is involved in writing a full Wayland compositor, and with this imagined native Wayland client support, you'd be a Wayland compositor anyway.

Frankly speaking, giving Mir support for Wayland clients would make MirAL arguably the best Wayland compositor library that exists, and one that's intended for more than the tiled use-case. The only compositor (beyond perhaps Weston itself) that I've seen uses libweston is WayHouse, as shown in an article less than a month ago. Correct me if I'm wrong, but I'm pretty sure this would be a good thing.

This is exactly what I have wanted the whole time. While the idea to support any server with any client is great (and Wayland certainly got part right) having the current status quo with at least four serious efforts with Gnome, KDE, libweston and qtwayland display servers all designed for modern desktop environments is a serious waste of effort.
If this can be done (TBH. I think this is more of a hope by Alan rather than an actual belief in that he can talk Canonical into it) it would be great for all desktop environments that aren't Gnome and KDE as they would have a much easier time. With the current approach I only see Gnome and KDE being the ones with enough resources to have good support for multi-monitor, multi-gpu, hybrid gpus and other non trivial things.

[BwackNinja]

Yeah let's make Mir into middleware

Let's make sure to keep using MirAL as middleware

Let's make even more layers of middleware. Yay middleware!


The real answer to the question is HELL NO.

You may be brimming with sarcasm here, but optional middleware is exactly what people want here. We've got wlc, swc, libweston, all libraries used to ease the creation of Wayland-compatible compositors. Gnome, KDE, Enlightement and Liri OS are the entities large enough to create Wayland compositors without use of these libraries. Everyone else relies upon them and another aid in doing so only opens the door for more developers to help make Wayland a reality for more than the few adventurous individuals using it now. You greatly underestimate the current difficulty in writing a Wayland compositor.

[bregma]

I'm actually starting to get concerned here. Has this really devolved into nothing more than a political discussion by people who have no idea what any of the terms involved mean?

It has never been anything but.

We're talking about Mir literally becoming a Wayland compositor as well here. That is concentrating effort into Wayland, unless you think that having Mutter and KWin running as Wayland compositors is similarly a waste of effort.

The idea of "just port Unity 8 to Wayland" is a laughably absurd notion missing any understanding of where the shell fits within the stack. Wayland is still a protocol, not another display server for things to run on top of. This would mean making Unity 8 a Wayland-compatible compositor itself, giving it at least a DRM backend and the same support for Wayland clients that we're talking about in the first place. When we're talking about Wayland, the concept of a 'window manager' or a 'desktop shell' as separable concepts is at best an implementation detail of a specific compositor and not the only requirements of such.

Mir has a DRM backend as well as an X backend, it has the additional protocol to be able to handle a shell of it's own and the externalization of window management capabilities. Window management policies aren't restricted to floating windows, it also supports tiled, phone, and tablet styles of window management. You can do these things while writing drastically less code than is involved in writing a full Wayland compositor, and with this imagined native Wayland client support, you'd be a Wayland compositor anyway.

Frankly speaking, giving Mir support for Wayland clients would make MirAL arguably the best Wayland compositor library that exists, and one that's intended for more than the tiled use-case. The only compositor (beyond perhaps Weston itself) that I've seen uses libweston is WayHouse, as shown in an article less than a month ago. Correct me if I'm wrong, but I'm pretty sure this would be a good thing.

Finally, someone who definitely understand what they're looking at. You're probably lost and looking for directions?

[sarmad]

Sure, if Mir is made compatible with Wayland then why not? I would love to see Unity 8 become a Wayland server and eventually get delivered.

[sarmad]

Yes, please. Make Mir a Wayland compositor and get it delivered alongside Unity 8. We'd love to see that happen.

[franglais125]

MirAL arguably the best Wayland compositor library that exists

I'm not saying it's not the case, but this sounds entirely subjective. What are the technical reasons, or specific context, for this claim?

[Holograph]

You may be brimming with sarcasm here, but optional middleware is exactly what people want here. We've got wlc, swc, libweston, all libraries used to ease the creation of Wayland-compatible compositors. Gnome, KDE, Enlightement and Liri OS are the entities large enough to create Wayland compositors without use of these libraries. Everyone else relies upon them and another aid in doing so only opens the door for more developers to help make Wayland a reality for more than the few adventurous individuals using it now. You greatly underestimate the current difficulty in writing a Wayland compositor.

I'm not against middleware per-se, I'm just against having too damn many layers of the stuff.

[Marc Driftmeyer]

For the life of me I am at a loss to figure out how much effort could be wasted in display server development and protocols when Quartz/Quartz Extreme [Display PDF, etc] developed for as Display Postscript at NeXT [alum here] and later at Apple [alum here], but then I look back to the original development of X versus NeXT Display Postscript and NeXT WindowServer both proven to be light years ahead of MIT-X and can't imagine after nearly 33 years it has taken this long to realize your designs were failures.

Wayland woke up and recognized Quartz/Quartz Extreme and went, ``let's do something more like that.''

Yet, there are still pissing contests over decades of failed decisions. None of you folks knew something Mr. Jobs knew from the first day he co-founded Apple, either ship it or bury it.

[Pajn]

I'm not saying it's not the case, but this sounds entirely subjective. What are the technical reasons, or specific context, for this claim?

There isn't that much competition really. Mutter and Kwin is both pretty specific to their own desktop environments so if you want yo write your own DE you pretty much have the choice libeweston and qtwayland. qtwayland is till far from usable for a full desktop though so it's only libweston that it's interesting to compare against.
I'm not qualified enough to do a detailed comparison between Mir and Libweston, both are high quality technologies.
IF (that is still a pretty big if though) Canonical does have paying customers for Mir and will continue to maintain it, Mir do have better backing as most red hat sponsoring goes into Mutter and not Libweston.
One could argue that Mir have an advantage with the C++ codebase and while everyone does not agree on that, I guess many of those that currently uses QTWayland does and Mir is in a better shape than it...
However having two high quality tools for DEs to build upon would only be good for the community.

[TheBlackCat]

Mutter and Kwin is both pretty specific to their own desktop environments so if you want yo write your own DE you pretty much have the choice libeweston and qtwayland..

Not only is this not true for Kwin, but Kwin is being used by another DE, lxqt.