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-kms
is implemented using the mesa/kms desktop graphics stackmesa-X11
is implemented using X11 and mesa (i.e. âMir-on-Xâ mode)android
is 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.