Wayland anybody?

Is there any experience with Ardour running on Wayland out there?
Any known issues?

I ran it for like a month or two. There are no problems as far as I could see, or that I could connect to Wayland. I had to go back to X for other reasons.

Plug-ins currently need X11 for their UIs. This will likely to be the case for some time (if not forever). There are currently some (incompatible with each other, non-‘standard’ - for some definition of ‘standard’, etc, etc) bespoke ‘solutions’ to making Wayland ‘compatible’ plug-ins (note the heavy use of quotation marks…) but until some kind of consensus is reached, I suspect most host applications will need to run as X11 applications, for example using XWayland on Wayland native systems. Its basically the UI toolkit wars all over again as far as plug-in GUIs go, only this time it even extends to the underlying graphical subsystem.

1 Like

I’ve been using Wayland now for probably over a year, due to some apps that I found that didn’t seem to work well in X11.

I’ve had a few little issues with it, but nothing major. Probably the biggest issue is that some legacy apps don’t quite behave as they should when run with Xwayland.

For example, I used Krdc for some remote desktops with the freerdp plugin. FreeRDP should run within the Krdc window, but it tends to open it’s own window. There’s an environment variable you can set to stop it doing that. It took me a while to find, but it’s a simple fix.

Probably the only other issue I have had is if I hotplug a screen, it screws up the mouse coordinates, so the mouse pointer appears in the wrong place on the new screen.

I’ve used Ardour in it with no issues, including plugins.

I recently came across a bug which caused Ardour to crash, and my original assumption was it was a Wayland issue, but I rebooted into X11 and it did the same thing.

I will disagree with this somewhat as the underlying components of Xserver are, effectively, abandonware now, although (thankfully) some work is still going on to fix the worst of the security issues that come up, but I suspect that will, eventually, start to decline.

Yes, there’s been some spirited debate amongst users on the merits of X11 vs Wayland, but these seem to have been confined to end-users. As I see it, there’s no significant debate amongst the developers and maintainers of Xorg, who seem happy for there to be a future without X11.

Even NVidia, who were one of the last dissenting voices supporting X11, are now supporting Wayland…

Plugins only “need” X11 because they’ve been written with toolkits which use X11. I don’t see any reason why a plugin couldn’t be written with a GUI using toolkits that natively run on Wayland.

On the other hand, I don’t see any compelling reason to do so, as XWayland works and writing such a GUI would break compatibility with users who are still using X11.

The way I see it, XWayland mostly works pretty well, and the developers anticipate it being required as a compatibility layer for the foreseeable future, and will continue to support and develop it, and people will continue to use it whilst X11 based distros exist, and probably beyond that.

There may be a point in the future where the majority of tookits and applications are completely Wayland native, but I think that’s a long time in the future. It seems to me that the immediate future is applications running in Xwayland, and for some of us, that’s already here.




The problem has always been (and still is) that for Linux host applications, a plugin developer can’t know in advance which UI toolkit a host will be using (e.g. Qt, GTK ( and which GTK?) ) and can’t realistically target all of them, and they don’t play together well in a single application - and why should they.
On Windows (and MacOS) one can logically assume that there will always be e.g. an HWND, or an NSView because its a fundamental part of the OS GUI. The equivalent on Linux, the ‘lowest common denominator’ which you could know would be present on all recent distros was X11 (and an XWindow ID).
‘Native’ Wayland support breaks this (actually ‘Wayland’ as far as I understand it isn’t even a window manager in any sense that is similar to other OS, its a compositor, so the concept of being able to ‘create a window’ for the plug-in in the conventional sense (or even embed a plugin window in a host) is not even represented in the same way.
An application / plugin developer would have to do all the traditional window management functions instead, presumably, or use some add-on toolkit (but which one, and presumably only the one the host uses etc)
This is kind of a unique to audio (and you could argue unique to Linux) ‘edge case’ - as a plugin developer, its frustrating because I need to target as many host applications as possible just to make it viable. And given that in many cases the GUI is 90% of the plug-in (yes, really) maintaining 3 or 4 different strands, just for one OS is impractical.
(My solution was actually to write my own DAW, with its plugin format, and embedded UIs, but that’s just the kind of random sh*t I would do, I really don’t recommend it…! ) it took me six months to get to this -

(And when I say ‘DAW’ its more just tracking with some editing, automation etc and its unlikely to ever be anything other than a personal project but I digress)

</shameless self promotion>

I guess we’ll just have to see what eventually evolves as common consensus around native Wayland support. In the meantime XWayland seems to do the job. And there are some other plug-in extensions (Presonus I think have something)


I use Wayland in Ubuntu Studio.
The only problem I get is when I use plugins (some of them) in Yabridge. But I don’t know if it’s because of Wayland or because Wine doesn’t support Mesa for my video adapter (Haswell Vulkan). I really don’t know about these things.
The issue is that I need to use OpenGL to see some plugin monitors (e.g. spectrograms).
Some of them don’t re-render when I use a control (say a slide). I have to move the plugin dialog to see the change.

You may have to switch to X11. I had to.