Hi, thx again for this graphical representation (and everything else)! As requested, here my two questions i asked via Telegram:
- The libmirclient/libwaylandclient is this the same as the compositor (e.g. kwin)?
- Does this mean that walyand apps can run on a mir server AND mir apps can run on a wayland server or only one way?
And the answers were:
- no, libmirserver is the analog of qtwayland, mutter, kwin or weston
- no, only wayland apps run on any wayland server (Mir, qtwayland, mutter, kwin or weston)
Thanks for preserving that discussion here.
[reposted from http://voices.canonical.com/alan.griffiths/2017/09/19/mir-support-for-wayland/]
I’ve seen some confusion about how Mir is supporting Wayland clients on the Phoronix forums . What we are doing is teaching the Mir server library to talk Wayland in addition to its original client-server protocol. That’s analogous to me learning to speak another language (such as Dutch).
This is not anything like XMir or XWayland. Those are both implementations of an X11 server as a client of a Mir or Wayland server. (Xmir is a client of a Mir server or and XWayland is a client of a Wayland server.) They both introduce a third process that acts as a “translator” between the client and server.
The Wayland support is directly in the Mir server and doesn’t rely on a translator. Mir’s understanding of Wayland is going to start pretty limited (Like my Dutch). At present it understands enough “conversational Wayland” for a client to render content and for the server to composite it as a window. We need to teach it more “verbs” (e.g. to support for the majority of window management requests) but there is a limited range of things that do work.
Once Mir’s support for Wayland clients is on a par with the support for “native” Mir clients we will likely phase out support for the latter.
We’re still testing things prior to the Mir 1.0 release, and Mir 1.0 will not support “everything Wayland”. If you are curious you can install a preview of the current development version from the “Mir Staging” PPA.
In response to one of my Reddit posts, I’ve been asked to what “mesa-X11” and “android” refer in your graphical representation.
I’m guessing that “mesa-X11” probably refers to running X Clients under Wayland (XWayland).
Also, I’m guessing (with even less confidence) that “android” in your graphical representation serves to demonstrate that Mir will display diverse Wayland clients, potentially even containerized Android apps displayed as Wayland clients.
Are my guesses correct? If not, would you please clarify?
I should explain that the basis for my guess regarding the significance of “android” in your representation is that Google’s Arc++ relies, at least in part, on Wayland for window management and input related communication between containerized Android apps and Chrome OS.
I hope that someday we’ll see Anbox working in conjunction with Mir.
I’m afraid your guesses are wrong. It’s my fault for reusing a presentation slide without any of the context that it originally had.
Mir has plugin modules that adapt it to different graphics stacks and mesa-kms, mesa-X11 and android are three of these plugin modules. They relate to the underlying hardware drivers, not to the client applications.
mesa-kmsis implemented using the mesa/kms desktop graphics stackmesa-X11is implemented using X11 and mesa (i.e. “Mir-on-X” mode)androidis implemented using libhybris and android drivers (used by Ubuntu Touch)
The UBports project has also done some work on a wayland plugin module, but I’m not sure of the current status of that work.
That sounds like the interaction would be entirely through the ‘libwayland-client’/‘libmirserver’ interface. We’ve not yet introduced support for any window management extensions, but that is work we are planning. If you have specific requirements then the Discuss supporting Mir - Mir - Ubuntu Community Hub thread would be a good place to bring them to our attention.