[WIP] Wayland support - #340
Conversation
|
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
|
|
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 |
|
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.
|
|
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 ( |
|
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 
|
|
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 |
|
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. |
|
Tested with latest commit. Session starts fine with LightDM, SDDM or from TTY. |
|
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. |
|
WCM saves config in |
|
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
|
|
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. |
|
Looking at gsm-compositor.c it looks like we build the path to the intended wayfire.ini OK, but Looking at the wayfire man page, the only arguments wayfire itself takes are |
|
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. |
|
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 |
|
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 |
|
Latest commit fixes Xwayland issue for me, e.g. Steam is properly launched from menu or terminal |
|
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
|
|
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. |
|
What seems to be broken in plugins is all of the plugins that can show the workspaces together: cube, expo, etc |
Does this plugins work if you disable ext-workspace plugin? |
|
Disabling that seemed to have no effect but I am NOT certain wayfire is reading from the same wayfire.ini file that
is being edited. Very buggy trying to apply anything that way right now.
EDIT: disabling it in BOTH of the wayfire.ini files (in ~/.config/ and in ~.config/mate) had no effect either, oddly did not even disable the panel switcher. I have to wonder what is and is not being applied at this point
|
|
The newly added protocols are all already in my default wayfire.ini file for this, though no idea what is actually being applied |
|
mate-session reads |
|
OK, good to know. For some reason WCM is writing back to /home/luke/.config/wayfire.ini
and probably reading from it as well
|
|
I am trying symlinking ~/.config/wayfire.ini to ~/config/mate/wayfire/wayfire.ini to get wcm working. |
|
That works, I now have the cube and other plugins working again. We need to get wcm to find the file wayfire is running from so plugins can be activated. With wayfire.ini found and wcm working via the symlink I now have my session working with this setup |
|
We have an issue if the compositor is terminated or crashes: something keeps running and prevents the greeter from coming back up at least on SDDM. Logout works fine, but if the compositor is killed with ctrl-alt-backspace (same as killing an Xorg session on wayfire) SDDM hangs. This implies a compositor crash would also hang SDDM. Only way I've found out of it (on a systemd system) is to log in on another tty and run |
|
Please check the latest commit |
|
A test build with today's changes still hung SDDM on killing the compositor.
|
|
Just tested on x11, there the desktop comes up unresponsive but becomes responsive after about a minute or so. Killing x11 tends to incompletely exit the session just like in wayland, but with a twist: some process is surviving in such a durable way that it takes a minute or so just for |
I have tested a bunch of solutions, but result is the same: no login screen, black screen with blinking cursor. That's because Wayfire starts as mate-session's child, not SDDM's. So when it crashes/exits, mate-session' process remain launched and prevents SDDM login screen to appear. In order to change it, we need to return to wrapper-based solution, just like xfce4-session and lxqt-session does: compositor should start first, as display manager's child process. And then launches session itself. |
|
Would it be possible to determine if the compositor is still running and terminate the session if it is not?
Also note that if wayfire gains support for relaunching and reconnecting after a crash in the future (as KDE
was reportedly working on a while back) we'd want to be able to take advantage of that
|
Yes, and the proven way (lxqt-session and xfce4-session) is to detect it architecturally rather then polling inside the session manager. SDDM only restarts the greeter when the process it launched via the session file's
This is the other side of the coin - KDE-style reconnect needs the session manager to survive while a restartable compositor relaunches - i.e. session first. Wayland clients now die when compositor's socket closes, and Wayfire (and wlroots itself, as far as I know) doesn't support client reconnect, so we have to make compositor-first now. To keep that door open, we're centralizing policy at one explicit point (e.g. compositor-death-policy key + hook), so that when Wayfire gains |
|
This is sort of how my shell script based wayland session has worked: wayfire is started with a custom
wayfire.ini that includes the script for a simplified mate-session in the autostart list. That of course
could have been a binary but I have little experience launching binaries from inside other binaries
and almost none with the original session manager code. It exited fine, since wayfire was launched
by SDDM and everything else by wayfire. I had actualy tried to launch the session stuff from outside
wayfire but never figured out how to connect it to the compositor.
Basically I had to whip up something simple to get a usable wayfire based session that didn't require starting
everything by hand from a bunch of terminals inside a bare wayfire session. That of course was how I developed
my original panel, applet, and caja support for wayland, which in turn built on some still earlier work by others
I think from 2018 or so.
|
|
I return to the wrapper-based solution: Wayfire now starts first, then launches mate-session in it's auotostart section. The One caveat: terminate session is using logind, so the whole Wayland session is depends on systemd, so it cannot be used in other init systems or OS, like FreeBSD. |
|
Note that MATE is used by a lot of the same folks who object to systemd for various reasons.
EDIT: I see you included elogind to cover non-systemd users. That will save us a lot of trouble and should make this good to go once the session comes up reliably
|
|
Just tested this, got a bare wayfire session without the rest of the session started, every time. This happened before on occasion, not it happens consistantly. Brought up the desktop by running the wayland-components.sh script from the old wayland session from a terminal. (EDIT)I see that we only kill the compositor after the session exits with this code. It looks like the rest of the session is trying to start up outside the compositor without connecting to it. |
2 participants
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:startmatewaylandwrapperorg.mate.session, session startup capplet, etcext-idle-notify-v1protocolwayfire)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