Wayland based session?

[howels]

Hunting around to see what might happen in Ubuntu 24.04 timeframe with Mate, and spotted someone who enabled Wayfire with Mate.
Thought it might be useful: https://github.com/lukefromdc/mate-wayland-session

[lukefromdc]

The experimental wayland session is now developed here at
https://github.com/mate-desktop/mate-wayland-session
about to push some updates to README

[fish4terrisa-MSDSM]

Is there any further updates? It seems that all parts of mate are ported to wayland.
Is it possible to have pure mate running on wayland?(With marco, NOT depending on Wayfire or any other WM, just like what gnome did)

[lukefromdc]

That would require us to write our own compositor from scratch. That is well beyond my ability, and right now we don't have anyone else on the team coding much wayland stuff. I've had incredibly valuable help from multiple team members getting mate on wayland working of course, but the work I built it on dates back to 2019. The most likely approach would be a fork of wayfire, mostly to follow the MATE and not the GNOME gsettings. This however would mean we'd have to then maintain the new compositor. This in turn would be still more fragmentation of the wayland ecosystem, though using wlroots as the basis would prevent most potention compatability issues. MATE running on x11 with compiz isn't "pure MATE" either as Marco is not in use and the control center does not manage compiz settings (CCSM does). MATE on compiz is a lot like MATE on wayfire though of course not identical. MATE and compiz together seem to be very popular

[fish4terrisa-MSDSM]

That would require us to write our own compositor from scratch. That is well beyond my ability, and right now we don't have anyone else on the team coding much wayland stuff. I've had incredibly valuable help from multiple team members getting mate on wayland working of course, but the work I built it on dates back to 2019. The most likely approach would be a fork of wayfire, mostly to follow the MATE and not the GNOME gsettings. This however would mean we'd have to then maintain the new compositor. This in turn would be still more fragmentation of the wayland ecosystem, though using wlroots as the basis would prevent most potention compatability issues. MATE running on x11 with compiz isn't "pure MATE" either as Marco is not in use and the control center does not manage compiz settings (CCSM does). MATE on compiz is a lot like MATE on wayfire though of course not identical. MATE and compiz together seem to be very popular

Emmmm... I use pure MATE(with marco, no compiz) I'll try to find out whether it's possible to make marco act as a wayland compositor for mate later

[lukefromdc]

Marco is of course an x11 window manager. Note that it is not the xserver itself. In wayland the compositor and window manager are the same program. In KDE there is the kwin window manager and kwin_wayland compositor for wayland, these are separate programs. in GNOME, gnome-shell is a Mutter plugin, and I'm pretty sure mutter includes in one binary both the x11 window manager and the compositor. I do not know how GNOME did this, but I can see at least two possible approaches. One would be to split it into a frontend handling window management with the x11 specific code moved to an x11 backend layer, plus a wayland backend accepting the same inputs. This could load as one binary or to reduce RAM use be split into three of which only two would ever be loaded at once. Alternately, and x11 and wayland codepath could be included in the same binary, which one is run being selected by whether x11 is running or a wayland session is being started. Wayland sessions normally start with compositor startup, so the starting point would be different. For the wayland session, the compositor would start first, listen for clients, and its internal autostart function start the rest of the session. This can be done by calling a session manager, I have a simple version of that in mate-wayland-session where the startup script that starts wayland and handles first run configuration calls a second script to start the session components. That can of course be a binary rather than a script. Again I am not sure how GNOME or KDE do this. Note that for a single binary where all components are loaded but the codepath changes, the starting point changes. Thus we'd probably have to start up, detect x11 or wayland, and then jump to the real starting point for the correct session. In x11 we'd want to change as little as possible: session starts first with x11 already running, window manager can start or be replaced at any time. Note that the MATE session under x11 is called from inside the running xserver (often but no longer always from the display manager running under the same xserver instance), just as for the wayland session we start the compositor first, then the rest of the session. Theoretically, we could have a mate-display-manager supporting one or the other, but starting whichever session it was NOT running under would still require starting the xserver or wayland compositor first. Biggest difference with x11 is the window manager being split out, replaceable, and able to crash or be terminated without killing running apps. This is because the apps only need to talk to the xserver, which does take down all the apps if it crashes just as a wayland compositor does. There are efforts in Kwin and GNOME to include "keepalive" sockets that an app could use to keep running if the compositor crashes until it can be restarted. Extending this to allow the apps to talk to any new wlroots-compatable compositor at the restart would allow changing compositors on the fly, which would be unique to MATE until others caught up./