Wayland support

[wmww]

This is the PR we've all been waiting for. The one that finally adds full Wayland support to the panel. You can test this without even building from source (see the Mir section of 'To run')

Based on #983, #984, #985, #986, #988, #989, #990

To build

You'll need to compile and install GTK Layer Shell. After that run ./autogen.sh --with-in-process-applets=all --enable-wayland --enable-x11 and make and install. Installing is required if the build that is currently installed did not have --with-in-process-applets=all. If you don't install it will try to use out-of-process applets, which fail on Wayland.

To run

First, you'll need a Wayland compositor that supports Layer Shell.

• Wlroots based compositors
  • On sway the basics work, but popups don't (so you can't add to the panel or open properties)
  • If you compile wlroots from source you'll get rootston. Nested popups don't work but at least toplevel ones do.
• Mir
  • The normal Mir demos don't have layer shell enabled
  • The mate-wayland snap is built from a branch of Mir with Layer Shell. It also comes with a copy mate-panel compiled from the same commits as are in this branch.
  • To install on a system that supports snaps: sudo snap install --edge --classic mate-wayland
  • To run Mir and the bundled version of mate-panel: mate-wayland
  • To run just the version of Mir with Layer Shell support: mate-wayland.mirco

If compiling the panel yourself, once you have a compositor with Layer Shell support you'll want to run mate-panel in it. To do this, run WAYLAND_DISPLAY=wayland-0 ./mate-panel. That's assuming your Wayland compositor is running on wayland-0 which I think is a safe assumption if it's the only compositor running.

[lukefromdc]

I tested this under Wayfire, it did in fact build and run under both X and wayland. Had trouble on x11 with some out-of-process applets not showing up on x11, not being successfully addable, and showing a 1px vertical line where they were supposed to be. Trash, CpuFreq, sensors, and volume control applet all were affected. Worse yet, having run this corrupted the panel configuration so it was necessary both to roll back the panel version AND to reset the panel (lots of fun with a heavily customized panel) to get back proper x11 rendering. This though also happened with the last Wayland support branch, and can be evaded by testing only as a different user.

Now to Wayland results: I have an old version of Wayfire installed, from March 2018 and that's what I tested with on wayland. Panel started up fine, and x11-only applets simply didn't load and brought up the delete/don't delete dialog. Had a problem with the panel rendering partway across the screen when a smaller secondary monitor was hooked up, but that could have been a wayfire issue just as easily. Also menus rendered out of position and some could not be popped back down. Again, this is NOT one of the compositors mentioned in the test instructions, but I had it installed and ready to go, and the panel DID run, even though a lot of applets are not yet wayland-ready.

Not one of the problem applets on x11 should be wayland-incompatable once ported to in-process, in fact all applets in-process would have entirely prevented that bug and only in-process can be used in wayland as we don't have Xembed thus don't have GtkPlug and GtkSocket.

Lots more to do but nice work, again this does in fact run on both wayland and X11, however rough at the moment.

[lukefromdc]

The configuration corruption ideally would be the FIRST thing fixed here, as it makes testing very difficult. Trying to run wayfire as another user did not work for me, I thought I had copied over the necessary files but I got a hard freeze.

[wmww]

Hmm... it seems there are issues even on master when switching between out-of-process applets and in-process applets. Now on master in X11 I can't get fish or clock to show up (even after compiling with both in-process and out-of-process, uninstalling, installing and resetting).

[wmww]

Here is what I have found (all this applies to master with --disable-wayland):

• After switching from in-process to out-of-process, applets aren't shown
• Reinstalling, resetting, etc don't fix the problem
• Rebooting the computer after reinstalling does
• Switching from out-of-process to in-process appears to work?

I'm not sure if this is the same or related issue as the one you're running into. I'll continue to look into this.

[wmww]

I have no confirmed that something is indeed broken on this branch in a way it is not broken on master. out-of-process applets don't work on X11 even when compiled without --disable-wayland. Each iteration of debugging requires a reboot, which is significantly hurting my workflow.

[wmww]

Fixed it. One stray !.

[lukefromdc]

The last commit entirely fixed the out of process applets on x11, throwing open the door for full-on wayland testing. Starts and runs under my old (march 2018) wayfire install, though menu and calendar positions are wrong with that compositor. Wayfire of that age might simply not properly support gtk-layer-shell's features for all I know, but it does in fact run and the menu, in-process clock, and some other applets such as the shut down applet come up fine.

Lots more to do, but this does in fact run on Wayland WITHOUT apparently breaking anything on x11

[wmww]

All menus should be positioned correctly (update GTK layer shell if not), but calendar is not currently implemented as a popup or layer surface, so it is out of place. Also the drawer applet appears to spawn temporary toplevels, which get attached to the edge of the screen like normal toplevels.

[lukefromdc]

Main menu on bottom panel opens flush w bottom of screen on bottom panel, as does panel context menu. Looks like panel struts do not work or are not yet implemented (or replaced if this is x11-only). Might be an anchor point issue in the menu popup function doing this though

Menus on top panel mostly in right place, with exception of main menu's context menu, which came up out of position with a menubar NOT all the way to the left: menu context menu was offset down and to the left.

Menus can be closed by clicking on a menuitem or by clicking on the rest of the panel.

Panel still comes up short with two monitors connected, secondary monitor smaller resolution than primary. This might be a Wayfire issue on my end passing a wrong monitor dimension to the panel

[lukefromdc]

This change fixes menus on bottom panels but causes menus on top panels to render level with the top screen edge instead of the panel edge. Also at least on X11 a menu button on a vertical panel at the top or bottom of the panel will have the menu offset from the top or bottom screen edge (or edge of a separate horizontal panel) by the width of the panel:

in panel-menu-button.c panel_menu_button_popup_menu

Replace

gtk_menu_popup_at_widget (GTK_MENU (button->priv->menu),
                          GTK_WIDGET (button),
                          GDK_GRAVITY_NORTH_WEST,
                          GDK_GRAVITY_NORTH_WEST,
                          NULL);

with

gtk_menu_popup_at_widget (GTK_MENU (button->priv->menu),
                          GTK_WIDGET (button),
                          GDK_GRAVITY_NORTH_WEST,
                          GDK_GRAVITY_SOUTH_WEST,
                          NULL);

Thus here and in all other instances of gtk_menu_popup_at_widget we may need to detect the position of the panel.

[lukefromdc]

This is actually enough function on wayland to merge and polish later, as it is the difference between not running on wayland and minimal usability on wayland (you can read the time, launch applications, etc). We can worry about the calendar position, a wayland tray for SNI indicators and (the BIGGIE) a wncklet replacement integrated with a wayland compositor later.

Ideally we would handle the menu position now, but that could be another PR, especially as it might be complex.

[wmww]

Correct popup placement is supposed to be handled entirly by gtk-layer-shell without modification to the app (in this case, MATE Panel). Some (and possibly all) of these issues are bugs in wlroots and Wayfire.

I'll test in Mir to check (Mir is far from perfect currently, but at least it tends to not have the same bugs as wlroots). Its hard to tell exactly what you're observing from description alone. Anything you screenshot I'll be sure to test on both Rootston and Mir, and give an analysis of who's at fault.

EDIT: Screenshots of expected behavior from X11 are also useful. You don't have to screenshot anything in particular, but if you want to make sure I test something specific, thats the way.

[wmww]

I've started a document to track all the issues related to MATE panel Wayland support, and where they need to be fixed: https://oasis.sandstorm.io/shared/F7QcAtod2QaYEv7n5vLzqcYHa1Sw71OQFxxi3n6fj5x

[lukefromdc]

I notice we now have a merge conflict, that will need to be fixed

[lukefromdc]

heads up: Red Hat is indication they are de facto deprecating Xorg itself, saying it is about to go into "hard maintainance mode."

https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Maintenance-Mode-Quickly
based on
https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/

"Once we are done with this we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time"

This means we may need to move Wayland development up as a priority, as the "bitrot" warning implies we may be looking at corner case distros that can't build X at all not that far down the road.

[lukefromdc]

The merge conflict is gone as shown both here and in a local test merge. Test build went fine, ran fine in Xorg, behavior in wayland same as last build: sure as heck it has come a long way from being unable to run.

[raveit65]

from https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/

We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, .........

https://access.redhat.com/support/policy/updates/errata/#Full_Support_Phase
version 8.8 will have Extended Life Phase support until 2025
Update Services for SAP Solutions ends 2027

Beside from this i think a plan will always have a delay.
Eg. python-2.7 was supposed to remove with fedora 29. Now we have fedora 30 since several month and it isn't removed ;)

[raveit65]

I like to setups a VM with a wayland-compositor for real testing.
So how can i start mir-wayland-compositor ( if this application exists) or wayfire with mate-session?
I am using lightdm + slick-greeter.
Does Caja (desktop handling) work with such a compositor?

[lukefromdc]

I normally start wayfire from another TTY, usually first ctrl-alt-F2 to TTY2, then login, then just run wayfire (which is what I have been testing with)

[wmww]

As I said in the original comment, there are a number of ways to get a Mir compositor with layer shell support (needed to run MATE panel). The simplest of which is to run sudo snap install --edge --classic mate-wayland

[lukefromdc]

I am on a heavily modified Debian Unstable install, do not have snap support installed, and don't plan to install it. No problem if this helps others test this, we all have our ways of doing things and in fact it is good if each tester is using different compositors and different install methods, as this helps catch corner case bugs. Thanks-we've got one more way people can test this

[raveit65]

I never used snap. No idea how this works :/
Again, Does caja work in this wayland session for handle the desktop?

[wmww]

AFAIK, Caja crashes on Wayland. You might get it working in XWwayland, but on Mir XWayland support is still sketchy. It's the next thing I'm going to look into porting to Wayland, though it will be a big job.

If you wanted Mir but not the Snap, you could build the mate-support Mir branch from source. Hopefully I'll get most of that landed in Mir master soon so you can just add the Mir PPA.

[raveit65]

AFAIK, Caja crashes on Wayland. You might get it working in XWwayland, but on Mir XWayland support is still sketchy. It's the next thing I'm going to look into porting to Wayland, though it will be a big job.

Ok, than it doesn't make sence for the moment to start a wayland compositor with Mate session from login manager.

If you wanted Mir but not the Snap, you could build the mate-support Mir branch from source. Hopefully I'll get most of that landed in Mir master soon so you can just add the Mir PPA.

I am using fedora , might be a good idea to start building a RPM package.
This is the mir compositor ? https://github.com/MirServer/mir
And what is this package, already packaged in fedora?
https://koji.fedoraproject.org/koji/buildinfo?buildID=1192508

Btw. my problem with snap is that i don't know how to use it.

[lukefromdc]

I do in fact have caja working on Xwayland in wayfire, and have also run it on xwayland in Weston. Even caja --force-desktop works, though there is the problem that the xwayland desktop window does not get forced to the bottom of the window stack. None the less, I have more than once had a wayfire/mate-panel/caja with desktop session running, a very rough early prototype for a MATE+ compiz replacement. Porting Caja itself to wayland would indeed be the next big step, and it will probably require a new desktop canvas. GNOME decided to ignore that and entirely dump support for icons on the desktop, something we simply cannot do.

[wmww]

And what is this package, already packaged in fedora? https://koji.fedoraproject.org/koji/buildinfo?buildID=1192508

That's Mir, but it doesn't have the layer shell stuff yet. That's why I mention building from the mate-support branch. Hopefully I'll have Layer Shell landed in Mir soon.

Btw. my problem with snap is that i don't know how to use it.

https://docs.snapcraft.io/installing-snap-on-fedora. You'll want to enable classic snaps (these are snaps that have access to the filesystem, instead of being restricted to their own environment). Then just sudo snap install --edge --classic mate-wayland

[wmww]

I'm not convinced the Wayland port would require rewriting the desktop. Gnome dropped it because they want to do that sort of stuff in-process in the shell, but with Layer Shell we can (and probably should) continue to render the background and icons with roughly the same architecture as on X.

[lukefromdc]

That's very good news, I thought the desktop would be the second worst problem after a replacment for what libwnck does in Xorg

[lukefromdc]

Just pulled and built today's version of this, no new problems. Also used a new wayfire install, the wayfire bugs with menu position (panel struts ignored, a WM issue presumably) are still there but presumably out of the scope of this PR.

An interesting problem with the clock: the calendar window was not only way out of position but decorated.

Looks like wayfire DOES use layer shell though, as attempting to run the panel on weston gets warnings gets a failure to render the panel with this warning (as we would expect):
** (mate-panel:31195): CRITICAL **: 23:44:13.200: Custom wayland shell surface is not a layer surface, your Wayland compositor may not support Layer Shell

[ddevault]

This sway patch gets this working on sway:

swaywm/sway#4307

[raveit65]

I've installed snap but something goes wrong with running mate-wayland in qemu VM.
Executed from a "normal" mate session under X.

[rave@f30 ~]$ mate-wayland
2019/07/07 11:55:30.273468 cmd_run.go:529: WARNING: XAUTHORITY environment value is not a clean path: "/run/lightdm/rave/xauthority"
Waiting for Wayland display to appear at /run/user/1000/wayland-mate...
[2019-07-07 11:55:30.377206] <information> mirserver: Starting
[2019-07-07 11:55:30.377382] < - debug - > mirserver: Not trying logind: "DISPLAY" is set and X need not have claimed the VT
[2019-07-07 11:55:30.377517] < - debug - > mirserver: Not using Linux VT subsystem for session management: Failed to find the current VT
[2019-07-07 11:55:30.377540] < - debug - > mirserver: No session management supported
[2019-07-07 11:55:30.377584] <information> VT switch key handler: No VT switching support available: MinimalConsoleServices does not support VT switching
[2019-07-07 11:55:30.377813] <information> mircommon: Loading modules from: /snap/mate-wayland/140/usr/lib/x86_64-linux-gnu/mir/server-platform
[2019-07-07 11:55:30.377883] <information> mircommon: Loading module: /snap/mate-wayland/140/usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.16
[2019-07-07 11:55:30.377905] <information> mircommon: Loading module: /snap/mate-wayland/140/usr/lib/x86_64-linux-gnu/mir/server-platform/server-mesa-x11.so.16
[2019-07-07 11:55:30.377914] <information> mircommon: Loading module: /snap/mate-wayland/140/usr/lib/x86_64-linux-gnu/mir/server-platform/input-evdev.so.7
[2019-07-07 11:55:30.380992] <information> mesa-kms: EGL platform does not support EGL_KHR_platform_gbm extension
[2019-07-07 11:55:30.381239] <information> mesa-kms: Failed to acquire DRM master: Operation not permitted
[2019-07-07 11:55:30.381320] <information> mirplatform: Found graphics driver: mir:mesa-kms (version 1.3.0) Support priority: 0
[2019-07-07 11:55:30.401044] <information> mirplatform: Found graphics driver: mir:mesa-x11 (version 1.3.0) Support priority: 128
[2019-07-07 11:55:30.401434] <information> mirserver: Selected driver: mir:mesa-x11 (version 1.3.0)
MESA-LOADER: failed to open virtio_gpu (search paths /snap/mate-wayland/140/usr/lib/x86_64-linux-gnu/dri)
failed to load driver: virtio_gpu
MESA-LOADER: failed to open kms_swrast (search paths /snap/mate-wayland/140/usr/lib/x86_64-linux-gnu/dri)
failed to load driver: kms_swrast
MESA-LOADER: failed to open swrast (search paths /snap/mate-wayland/140/usr/lib/x86_64-linux-gnu/dri)
failed to load swrast driver
ERROR: /build/mate-wayland/parts/mir-git/src/src/server/graphics/default_configuration.cpp(172): Throw in function mir::DefaultServerConfiguration::the_graphics_platform()::<lambda()>
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
std::exception::what: Exception while creating graphics platform
ERROR: /build/mate-wayland/parts/mir-git/src/src/platforms/mesa/server/display_helpers.cpp(330): Throw in function mir::graphics::mesa::helpers::GBMHelper::GBMHelper(const mir::Fd&)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
std::exception::what: Failed to create GBM device



[rave@f30 ~]$ WARNING: /run/user/1000/wayland-mate still doesn't exist, shell components will likely fail
Starting MATE shell components
	WAYLAND_DISPLAY: wayland-mate
	XDG_RUNTIME_DIR: /run/user/1000

(mate-panel:3784): Gtk-WARNING **: 11:55:34.416: cannot open display: :0

Looks like virtio graphic driver for qemu VMs isn't supported?
I am pretty shure i am doing something wrong because i don't know what i am doing and nobody tells me how to use mate-wayland in details.

Sorry, i am unable to test PR.

[raveit65]

offtopic on

I noticed today that libXxf86misc-devel is dropped from fedora rawhide (f31).
https://koji.fedoraproject.org/koji/buildinfo?buildID=1291079
From xorg dev Adam Jackson

Stop building the devel subpackage in Fedora and RHEL > 8, no new code should try to use this library, the X server hasn't implemented it in over 10 years

In result i have to build mate-settings-demon, mate-screensaver and mate-control-center without it.
I have no idea about the consequences.
Does anyone know for what libXxf86misc is used?
Or for what it is used by some of our main packages?
offtopic off

[raveit65]

Ok, i have the panel running in rootston window. :)

Do i have to re-compile the panel after updating gtk-layer-shell to latest version?
Should executing mate-wayland open a window too , similar to rootston window?

[raveit65]

Using qxl graphic driver for qemu VM gives me a different error message for mate-wayland

[rave@f30 Schreibtisch]$ mate-wayland
2019/07/07 16:22:25.964169 cmd_run.go:529: WARNING: XAUTHORITY environment value is not a clean path: "/run/lightdm/rave/xauthority"
Waiting for Wayland display to appear at /run/user/1000/wayland-mate...
[2019-07-07 16:22:26.865136] <information> mirserver: Starting
[2019-07-07 16:22:26.879422] < - debug - > mirserver: Not trying logind: "DISPLAY" is set and X need not have claimed the VT
[2019-07-07 16:22:26.898197] < - debug - > mirserver: Not using Linux VT subsystem for session management: Failed to find the current VT
[2019-07-07 16:22:26.898231] < - debug - > mirserver: No session management supported
[2019-07-07 16:22:26.898251] <information> VT switch key handler: No VT switching support available: MinimalConsoleServices does not support VT switching
[2019-07-07 16:22:26.898453] <information> mircommon: Loading modules from: /snap/mate-wayland/140/usr/lib/x86_64-linux-gnu/mir/server-platform
[2019-07-07 16:22:26.898824] <information> mircommon: Loading module: /snap/mate-wayland/140/usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.16
[2019-07-07 16:22:26.898851] <information> mircommon: Loading module: /snap/mate-wayland/140/usr/lib/x86_64-linux-gnu/mir/server-platform/server-mesa-x11.so.16
[2019-07-07 16:22:26.898863] <information> mircommon: Loading module: /snap/mate-wayland/140/usr/lib/x86_64-linux-gnu/mir/server-platform/input-evdev.so.7
[2019-07-07 16:22:26.917873] <information> mesa-kms: EGL platform does not support EGL_KHR_platform_gbm extension
[2019-07-07 16:22:26.920738] <information> mesa-kms: Failed to acquire DRM master: Operation not permitted
[2019-07-07 16:22:26.920862] <information> mirplatform: Found graphics driver: mir:mesa-kms (version 1.3.0) Support priority: 0
[2019-07-07 16:22:26.948858] <information> mirplatform: Found graphics driver: mir:mesa-x11 (version 1.3.0) Support priority: 0
ERROR: /build/mate-wayland/parts/mir-git/src/src/server/graphics/default_configuration.cpp(172): Throw in function mir::DefaultServerConfiguration::the_graphics_platform()::<lambda()>
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
std::exception::what: Exception while creating graphics platform
ERROR: /build/mate-wayland/parts/mir-git/src/src/platform/graphics/platform_probe.cpp(109): Throw in function std::shared_ptr<mir::SharedLibrary> mir::graphics::module_for_device(const std::vector<std::shared_ptr<mir::SharedLibrary> >&, const mir::options::ProgramOption&, const std::shared_ptr<mir::ConsoleServices>&)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
std::exception::what: Failed to find platform for current system



[rave@f30 Schreibtisch]$ WARNING: /run/user/1000/wayland-mate still doesn't exist, shell components will likely fail
Starting MATE shell components
	WAYLAND_DISPLAY: wayland-mate
	XDG_RUNTIME_DIR: /run/user/1000

(mate-panel:2166): Gtk-WARNING **: 16:22:30.467: cannot open display: :0
[rave@f30 Schreibtisch]$ 

Again, i have no idea what should happen here normally :)

[wmww]

Normally what happens is stdout shows about the same thing, but instead of errors there are more Mir messages, and then a new X11 window appears with Mate panel running on Mir inside. It appears there's some problem with graphics drivers running Mir inside the VM. I'll look into it.

[wmww]

I've reproduced running normal Mir (not from a snap) in an Ubutnu 18.04 VM. I opened an issue in Mir (canonical/mir#914) and will be looking into it.

[raveit65]

My results with rootston window:
main functions:

• add/remove panels --> works
• adding in-process applets --> works
• expand/unexpand the panel --> works
• background-color/transparency --> works
• background-image --> works
• changing panel size --> works
• changing panel orientation = works
• hiding panel/hiding buttons --> doesn't work
• context menu --> opens under cursor (good), but gravitation of menus are wrong for right and bottom panel. Here the menu is always outside the display with default panel size (24px).
• Moving an applet to left panel doesn't work if 4 panels are enabled (left/right/top/bottom).

menubar applet (3 menus), single-menu-applet (main-menu):

• context menu opens under cursor (good)
• menus are open fine if applet is used on top/left panel. With right/bottom panel menus are having wrong gravitation
• second menus (submenus) don't open.

panel-launcher, panel-action-button, execute-application-applet:

• menus are open fine under cursor, but gravitation of menus is wrong for right/bottom panel

fish applet:

• main window opens fine,
• only gravitation of context-menu is wrong if on right/bottom panel

drawer applet, clock applet:

• window position is wrong
• gravitation of context-menu is wrong if on right/bottom panel

Last but important point, It seems that same compiled panel with X11/wayland runs fine under X11 :)

So, what are your plans? I don't think you want to fix all those issues in this PR.
Maybe only the gravitation issue of menus and panel hide issue?
Than the main functions are done.
Or do want to do all in new single PRs ?

[raveit65]

I forgot, thanks a lot for this first implementation ;)

[wmww]

There are gravitation bugs, but I think they're more subtle than what you see in Rootston. The Wayland compositor is supposed to keep popups from going off screen, which Rootston does not last I checked. I think ddvault was working on that, but if any popups go partly or completely off screen it's a compositor issue, and probably wont happen in Mir.

The gravitation bugs that are in MATE panel are that popups tend to cover up their applets instead of appearing outside the panel. I'm not sure if the bug is in how gtk-layer-shell interprets GTK's popup position, or if GTK is positioning them wrong on X and there's some X-specific functionality to fix it.

Seeing as this is somewhat usable and doesn't break existing functionality, I would prefer to merge this and make fixes in future PRs.

[raveit65]

LGTM for a first wayland implementation.
The panel can build with wayland and X11 backends enabled, and there isn't a different to previous behaviour when running under X11.
Mentioned issues under wayland can fixed later in new single PRs.
Looks ready to go for me.

[raveit65]

@lukefromdc
Should we merge it?
I don't expect that anyone other from team has a setup ready to test this.

[lukefromdc]

Yes, I think we should merge this and fix the wayland-only issues as we go. After all, current master does not work with wayland at all, and this is a development version

[wmww]

@luispabon thanks for testing it out!

I think you're actually seeing correct behavior. There's currently no background app, so you're just seeing Mir's default black. There should be a panel somewhere, but it might be empty. Depending on your GTK theme it may even be solid black and blend into the background. Try right clicking near the top or bottom of the Mir-on-X window.

You can also run mate-wayland.panel from inside sway. That will launch the panel in your current sway session instead of in a new nested Mir session. Due to some issues of sway menus probably wont work, but you can check if it come up.

If you still have problems feel free to open an issue on https://github.com/wmww/mate-wayland-snap. I know I haven't been super clear about where what issues should be reported.

[luispabon]

Thank you @wmww, indeed running the pannel is what I needed to do 👍