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

[phoronix]

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

While Canonical is expected to maintain Mir for IoT use-cases, Ubuntu 18.04 LTS is expected to use the GNOME desktop on Wayland. The community forks so far of Unity 8 also appear to want to switch to Wayland eventually rather than Mir. In trying to maintain relevance for Mir, longtime Mir developer Alan Griffiths is asking whether the community would be interested in native Wayland client support in Mir...

http://www.phoronix.com/scan.php?page=news_item&px=Alan-Wayland-Clients-Mir

[bitman]

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.

[uid313]

Sounds like the path they should have gone with since day one before they wasted all that effort, resources and money into adding Mir support to Gtk+ and Qt.

Also, if Mir could handle native Wayland clients, then what would the purpose of Mir be? What does Mir offer here?

Also why would I want to run Ubuntu-only and Mir, when I can go with Wayland that all the rest Linux distributions are either using or migrating to?

I don't see what it would provide. I don't the value of Mir.

[TheBlackCat]

there’s no obvious technical reason that Mir could not support clients using libwayland directly

It isn't a question of why they shouldn't do this, it is a question of why they should. That is the key thing missing from the blog post: solid technical reasons why anyone would want to use Mir in this way rather than just having a conventional Wayland compositor. This has been a consistent problem with Mir from day 1, they haven't been able to provide technical, factually-correct reasons why anyone should want to use Mir to begin with.

[Mystro256]

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 a display server, like XOrg, which uses it's own protocol and interface for it's clients (applications) and driver (kernel/mesa). Alan is asking if it's valuable to add Wayland client support to Mir. I guess you could equate this to how Wayland supports XOrg clients via XWayland, but I would assume it would be less messy.

[TheBlackCat]

Reading the blog post again, I noticed these statements:

However with Snaps the client and server “snap”s package the libraries they use with the applications.That presents issues for keeping them in step. These issues are soluble but create an additional burden for Mir, server and client developers. Using a protocol based solution would ease this burden.

For the wider community native support for Wayland clients in Mir would make the task of toolkit maintainers and others simpler.

So, in other words, Wayland has a better architecture, and having to support Mir creates an unnecessary burden for third-party developers. This are exactly what critics of Mir have been saying since day 1, but that Mir developers have consistently denied. So it is nice to see Mir developers finally admit these issues were real.

[Mystro256]

It isn't a question of why they shouldn't do this, it is a question of why they should. That is the key thing missing from the blog post: solid technical reasons why anyone would want to use Mir in this way rather than just having a conventional Wayland compositor.

This has been a consistent problem with Mir from day 1, they haven't been able to provide technical, factually-correct reasons why anyone should want to use Mir to begin with.

Well I assume it would be useful in the short term, allowing Wayland clients to run with Unity 8 (or rather one of the forks). AFAIK migrating Unity 8's code to Wayland is no easy task (likely requiring large reworking of code if I understand correctly).

[sp82]

Please let's Mir and X die. Concentrate the effort into Wayland.

[Mystro256]

Reading the blog post again, I noticed these statements:

...

So, in other words, Wayland has a better architecture, and having to support Mir creates an unnecessary burden for third-party developers. This are exactly what critics of Mir have been saying since day 1, but that Mir developers have consistently denied. So it is nice to see Mir developers finally admit these issues were real.

I wouldn't draw the conclusion that Wayland has better architecture based on that statement, but rather it would be easier for developers to maintain only a single code path.

[curfew]

Well I assume it would be useful in the short term, allowing Wayland clients to run with Unity 8 (or rather one of the forks). AFAIK migrating Unity 8's code to Wayland is no easy task (likely requiring large reworking of code if I understand correctly).

Gnome and KDE are able to run on both Xorg and Wayland, so maybe something similar would be doable with Unity aswell. It depends on how much Canonical cared about such aspect, I guess they went all in and have integrated Unity with Mir without any effort to limit Mir dependencies to certain components only.