[WIP] Wayland support

[Sunderland93]

This PR adds support for Wayland in mate-session-manager. It incorporates some features from mate-wayland-session, e.g. config template, and aims to provide complete session management for Wayland:

• separate Wayland backend (X11 code is untouched), session is starts with mate-session --wayland
• provides org.mate.session, session startup capplet, etc
• idle monitor via ext-idle-notify-v1 protocol
• ability to change default compositor in settings or at build time (default is wayfire)

Tested in clean environment with Wayfire and some MATE components, like mate-panel, but needs more deeply testing and probably some Wayfire config tweaks.

Closes: mate-desktop/mate-wayland-session#16

[lukefromdc]

Once we have this working, we'll want to revert the wayland specific mate-panel code for the shutdown/suspend/hibernate button so it can use the session bus and thus listen for any inhibit signals

[Sunderland93]

I'm planning to revise the Wayland session startup sequence: currently, we launch Wayfire, which in turn launches mate-session, which then launches the rest of MATE components. The problem is that this creates several race conditions, and in certain situations, this causes Wayfire to crash. I want to try implementing Wayland session startup directly in mate-session itself, which will launch first and run the compositor and everything else. Similar to what's done for the X11 session. This will also allow you to change the desired compositor and store its value as a gsettings key. The only remaining issue is passing our predefined configuration to Wayfire (we copy it to the home directory the first time the script is run, but if mate-session is the startup process, we need to decide where to place our configuration and allow the user to upload their own).

[lukefromdc]

I found in my original testing that all GUI apps that will be accessable from the wayfire session as of 2023 had to be started from inside wayfire, using the autostart plugin and specified in the wayfire.ini file used. The way I managed to partially bypass this in the shell script mate-wayland-session is to add to the autostart list a single script (could be a binary just as easily though) which I named mate-wayland-components.sh and which in turn starts the panel, caja, mate-settings-daemon etc and handles autorestarting. Not the best approach but it works for now. I suppose the contents of mate-wayland-components.sh or even the wayfire.ini file could be written on the fly from a session though that might slow the startup. That is exactly what I do on first run to create a session with sane defaults as to theming etc.

[Sunderland93]

Found an issue with LightDM: it doesn't export $DISPLAY variable to child processes in Wayland sessions, so any apps that is child of Wayfire get wrong value for it (wayland-0 for both WAYLAND_DISPLAY and DISPLAY). So we probably need an workaround for LightDM that directly exports these vars to all compositor's child processes. GDM and SDDM is not affected by this issue.

[lukefromdc]

On an initial test run, I got this result using SDDM. Not installing GDM as it pulls in half of gnome-shell meaning more fs space to manage at backups and more bandwidth at updates. I haven't used lightdm since developing the original desktop session since at that time it wasn't yet showing wayland sessions. That's how I ended up using SDDM instead

The entire desktop was rendered in the top left at full scale but using only the top left portion of the screen . Below and to the right of the external camera image shown the greeter was still shown but was nonresponsive to any input. The desktop was also nonresponsive.

A lot had to be redacted in this image for privacy reasons of course

[lukefromdc]

I just got the desktop to open normally by running mate-wayland-session from a tty, but after many 15-30 seconds it crashed. I've had issues with a crasher in the network-manager-applet (which is not a MATE package) that for some reason crashes wayfire back to the greeter, so that may be the culprit but not sure. I do not know how to cut and paste an error message out of a TTY rather than a terminal app

[Sunderland93]

I'm almost done refactoring the Wayland session, getting rid of shell scripts. In my case, the session starts fine, but there's an issue with some environment variables, particularly DISPLAY. I plan to finish the refactoring by the weekend and publish it.

[Sunderland93]

Tested with latest commit. Session starts fine with LightDM, SDDM or from TTY.

[lukefromdc]

This now mostly works, a few times a bare wayfire session came up with all defaults, nothing in wayfire.ini applied and none of the MATE session but most of the time the session opened. I had to copy over my wayfire.ini from the shell script session with the part of it concerning the old session starter script removed to retain my usual settings, then applying a few was a bit cranky but that's probably a wayfire issue not an issue with this session. Notably, applying anything in wcm seems to reset the scaling to 1.0 which I had seen before in the old session but not in quite a while. Keeping mate-display-properties open stops that most of the time but not all of the time.

[Sunderland93]

WCM saves config in ~/.config/wayfire.ini, but we put our default config in ~/.config/mate/wayfire.ini and explicit pass it to Wayfire at session start. If we want to WCM can change default settings we need to put our default config in ~/.config/

[lukefromdc]

I am fine with keeping it in ~/.config/mate myself, as using ~/.config can break a parallel installation of wayfire with its native wf-shell I just found that in my setup here wcm is saving to ~/.config at least some of the time and that may explain some of the intermittant problems I've had

[lukefromdc]

I just confirmed that wcm (which normally saves to the same file that was read when wayfire was opened) is reading and writing from ~/.config/wayfire.ini with this session on my system. For now I have made the two files identical.

[lukefromdc]

Looking at gsm-compositor.c it looks like we build the path to the intended wayfire.ini OK, but config_path is loaded into argv[2] but I don't know enough about g_spawn_async () to tell if passing argv as a whole to it is correctly passing the config path to it.

Looking at the wayfire man page, the only arguments wayfire itself takes are -c or --config for the configuration path, -B or --config-backend for the configuration backend to use (is gsettings support coming?), -d or -- debug, -D or
--damage-debug, -h or --help, -r or --damage-renderer to rerender damaged regions, and -v or --version to print the version number. Thus I don't know what the rest of argv is doing probably just for lack of experience spawning binaries from inside other binaries. I've only done a little of that myself and by rather simple means

[lukefromdc]

The DISPLAY variable issue is not surprisingly causing a lot of issues with wayfire's plugins. Worst of all, Xwayland doesn't work, disabling quite a few programs. Also the cube cannot be rotated, probably nothing that requires fetching the display works right, and this may also explain the scaling resets I've had on closing WCM and all the problems I've had there.

No great surprise on a WIP under development, this is a normal part of building something new. You should have seen the first time I had a caja desktop showing under wayfire: it was under Xwayland, was decorated, could be moved, and did not stay on the bottom. So it always is in early development.

[Sunderland93]

It seems like DISPLAY issue is not in mate-session, but in mate-terminal itself: in other terminal emulator, like Konsole, or mate-terminal built from git, DISPLAY is :0 as expected. I'll investigate other issue with Xwayland and Wayfire plugins

[lukefromdc]

How old a version of mate-terminal are you using? The first stable release with fixes getting DISPLAY right in wayland was probably 1.28.0

[Sunderland93]

How old a version of mate-terminal are you using? The first stable release with fixes getting DISPLAY right in wayland was probably 1.28.0

1.26, but yes, I realize that mate-terminal 1.28 doesn't have this issue

[Sunderland93]

Latest commit fixes Xwayland issue for me, e.g. Steam is properly launched from menu or terminal

[lukefromdc]

Wayland support in any of MATE 1.26 is very minimal and this cannot be changed without breaking builds for distros. Normal rule is that same major version cannot get new features or especially new dependencies

[lukefromdc]

That got xwayland working, though the cube plugin is still broken and wayfire acts like it's not reloading the configuration after making changes in wcm. System is now mostly usable from this session though. Seems to be a bit less CPU use than the shell script based session, though on this 6 core that might be an illusion.

[lukefromdc]

What seems to be broken in plugins is all of the plugins that can show the workspaces together: cube, expo, etc