[WIP] Add Wayland backend

[affederaffe]

What does the pull request do?

Add a Wayland backend for Linux.
This PR is based on the previous one with significant bug fixes and easier maintenance .

In order to test this PR, locally building NWayland NuGet packages is required:
git clone --recursive https://github.com/affederaffe/NWayland next to the Avalonia directory

├── Avalonia
│ ├── samples
│ ├── src
│ ├── ...
├── NWayland
│ ├── src
│ ├── ...

Navigate to ./NWayland/src/NWayland.Scanner and dotnet run to generate the bindings.
Then dotnet build -c Release the ./NWayland/src/NWayland and ./NWayland/src/NWayland.Protocols.Plasma projects, which creates the required NuGet packages.

These steps won't be necessary once NWayland is released officially on NuGet.

TODOs:

• Better CSD integration
• IME

What is the current behavior?

XWayland is used in order to run Avalonia apps on Wayland systems.

What is the updated/expected behavior with this PR?

Use Wayland instead of X11 on compatible systems.

How was the solution implemented (if it's not obvious)?

Checklist

• Added unit tests (if possible)?
• Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/Documentation with user documentation

Breaking changes

None

Obsoletions / Deprecations

None

Fixed issues

Fixes #1243
Fixes #2338

[iMonZ]

Thank you so much for your work! I hope this gets merged into 11!

[iMonZ]

@affederaffe Do you think this can be still merged for the 11 update?

[affederaffe]

There are still some minor bugs to be fixed before merging and since Avalonia 11 seems to be moving closer and closer to RCs (feature freeze), I don't think we'll see this merged before 11.0. 11.x seems to be possible though, see the prior discussion

[danwalmsley]

There are still some minor bugs to be fixed before merging and since Avalonia 11 seems to be moving closer and closer to RCs (feature freeze), I don't think we'll see this merged before 11.0. 11.x seems to be possible though, see the prior discussion

11.1.

11.0 rc is coming in a matter of days and the team wont have time to test or review this in that time.

11.1 is likely to be very very soon after 11.0 however.

[affederaffe]

There's still some work to do:

1. Client Side Decorations: Probably needs support in Avalonia.Base Window itself, as pointed out, stealing client side pixels isn't a good idea
2. Touch support: currently just crashes when receiving a touch
3. IME support: currently in progress
4. NWayland NuGet package (submopdules are tolerable for my own development, but this approach won't work for master)
5. For a smooth transition, 3rd-party-support, most important video players: needs to use the library directly without window embedding, see libMpv (for example, mpvqt and libVlc. Embedding support is just not feasible as stated above
6. (optional) survive compositor crashes
   There's probably some more, those are just the things from the top of my head.

[cla-avalonia]

• All contributors have signed the CLA.

[barolo]

is this dead?

[kekekeks]

The plan is to figure something about CSD support in core avalonia and continue.

Alternatively we could release it without CSD for usage with embedded systems, wayland seems to be ready enough for those.

[affederaffe]

There are just too many unresolved issues, until I have the time and motivation to address those this PR continues to be WIP and thus unmergable from my perspective.
If everything goes well I'll probably have some time in September to work on some of these issues.

[slackerbob]

The plan is to figure something about CSD support in core avalonia and continue.

Alternatively we could release it without CSD for usage with embedded systems, wayland seems to be ready enough for those.

My understanding is that only GNOME requires CSD, and most other DEs are happy with SSD.

If that's true, then it might make more sense to just default back to X11 for GNOME, and use Wayland on everything else?

[affederaffe]

Even though I disagree with GNOME's philosophy to not support SSDs, they are still a major platform we cannot ignore. At least for me, it's full wayland support that works on every platform or none at all.

[fabiorush92]

My 2 cents on this topic: as an embedded developer I'm testing Avalonia and I noticed a trend: the latest implementations of Yocto/EmbeddedLinux (one of all for example NXP i.MX8) lack X11 implementation on graphics drivers by specific choice of the OEM. Therefore, at present, DRM is the only way to achieve hardware acceleration, with all the limitations of it (cursor and keyboard for example). In my opinion in the short/medium term Avalonia must have compatibility on Wayland to be 100% competitive on Linux, especially on the industrial/embedded side.

[Ammar-Sadaoui]

Even though I disagree with GNOME's philosophy to not support SSDs, they are still a major platform we cannot ignore. At least for me, it's full wayland support that works on every platform or none at all.

Once again, we should thanks the GNOME developers for sabotaging the Linux desktop.

[Ammar-Sadaoui]

These steps won't be necessary once NWayland is released officially on NuGet.

@affederaffe is there any alternative for NWayland in NuGet that work with your PR ?

[RiedleroD]

it's full wayland support that works on every platform or none at all

wayland support on KDE, wlroots and hyprland would improve support for those environments while not degrading GNOME's. I for one would highly apprechiate being able to run Avalonia-based programs with proper scaling. Additionally, I predict that GNOME will allow server-side decorations if enough programs exclude them from wayland support because of that.

[jgcodes2020]

it's full wayland support that works on every platform or none at all

wayland support on KDE, wlroots and hyprland would improve support for those environments while not degrading GNOME's. I for one would highly apprechiate being able to run Avalonia-based programs with proper scaling. Additionally, I predict that GNOME will allow server-side decorations if enough programs exclude them from wayland support because of that.

GNOME is pretty stubborn with their design philosophy. If anything, you could still rig crude decorations through libdecor until proper decorations are added.

[Ammar-Sadaoui]

it's full wayland support that works on every platform or none at all

wayland support on KDE, wlroots and hyprland would improve support for those environments while not degrading GNOME's. I for one would highly apprechiate being able to run Avalonia-based programs with proper scaling. Additionally, I predict that GNOME will allow server-side decorations if enough programs exclude them from wayland support because of that.

nope this will not work with gnome developers

prove : https://gitlab.gnome.org/GNOME/mutter/-/issues/217

[workgroupengineering]

If we wait for GNOME to implement SSD to release this PR we will all become centenarians. A fallback method could be added in the AppBuilder that is invoked when the server does not implement SSD. Each developer will implement their own fallback based on their needs

[Ammar-Sadaoui]

If we wait for GNOME to implement SSD to release this PR we will all become centenarians. A fallback method could be added in the AppBuilder that is invoked when the server does not implement SSD. Each developer will implement their own fallback based on their needs

the only way to wayland to improve is by everyone adopting it and start report issues and complain about missing features and demanding alternative

[Ammar-Sadaoui]

Do you have any plans to support libdecor for handling SSD-less compositors, like Mutter from GNOME?

Using XWayland in a Wayland environment has some drawbacks :

Performance Overhead: Adds extra processing, leading to potential performance drops.
Inconsistent Behavior: X11 apps might not integrate seamlessly with Wayland features.
Limited Features: Doesn’t fully support Wayland’s advanced features like high-DPI scaling.
Increased Complexity: Adds another layer, complicating system debugging.
Security Concerns: Inherits some security issues from X11.
Resource Usage: Consumes extra memory and CPU.
Incompatibility: Some Wayland features may not work well with XWayland apps.

[DocBrown101]

Do you have any plans to support libdecor for handling SSD-less compositors, like Mutter from GNOME?

Using XWayland in a Wayland environment has some drawbacks :

Performance Overhead: Adds extra processing, leading to potential performance drops. Inconsistent Behavior: X11 apps might not integrate seamlessly with Wayland features. Limited Features: Doesn’t fully support Wayland’s advanced features like high-DPI scaling. Increased Complexity: Adds another layer, complicating system debugging. Security Concerns: Inherits some security issues from X11. Resource Usage: Consumes extra memory and CPU. Incompatibility: Some Wayland features may not work well with XWayland apps.

And drag and drop does not work with with Wayland apps!

[Ammar-Sadaoui]

And drag and drop does not work with with Wayland apps!

When running X11 applications on Wayland via XWayland, drag-and-drop may not work as expected due to the compatibility layer's limitations. This is because XWayland translates between X11 and Wayland, and some operations (like drag-and-drop) might not translate perfectly.

and even in native wayland app its sill not wayland fault,
The Wayland compositor (like GNOME's Mutter, KDE's KWin, etc.) is responsible for managing drag-and-drop actions. If the compositor does not fully support or properly implement drag-and-drop functionality, it can cause issues.

sometime its app fault : Many applications were originally developed for X11, and not all of them have been fully adapted to work with Wayland. This can lead to missing or broken functionality, including drag-and-drop

plus : The Wayland protocol provides clients a mechanism for sharing data that allows the implementation of copy-paste and drag-and-drop.

maybe its your fault : dont use or support desktop that dont have implementation for standards like gnome or anything based on it and change to modern desktop for better and acceptable experience

ps: cosmic desktop is still in Alpha but they have good devs try it and make issuse if you find bug or problem be change you want to see in the world the linux desktop

[affederaffe]

Do you have any plans to support libdecor for handling SSD-less compositors, like Mutter from GNOME?

Using XWayland in a Wayland environment has some drawbacks :

Performance Overhead: Adds extra processing, leading to potential performance drops.
Inconsistent Behavior: X11 apps might not integrate seamlessly with Wayland features.
Limited Features: Doesn’t fully support Wayland’s advanced features like high-DPI scaling.
Increased Complexity: Adds another layer, complicating system debugging.
Security Concerns: Inherits some security issues from X11.
Resource Usage: Consumes extra memory and CPU.
Incompatibility: Some Wayland features may not work well with XWayland apps.

Using libdecor would pull in a Cairo/Gtk dependency, which is something I'm opposed to. I looked into using the current icon theme for drawing caption buttons though and at the moment this seems doable.

[amayra]

Using libdecor would pull in a Cairo/Gtk dependency, which is something I'm opposed to. I looked into using the current icon theme for drawing caption buttons though and at the moment this seems doable.

are you planning to support Client-side decoration (CSD) just for wayland ?

[IsaacMarovitz]

Using libdecor would pull in a Cairo/Gtk dependency, which is something I'm opposed to. I looked into using the current icon theme for drawing caption buttons though and at the moment this seems doable.

Interesting (and frustrating) that libdecor goes for Cairo rather than Skia, but yeah I don't see why accomplishing CSD on Mutter would be too difficult. The question is of course, do we bother trying to conform to Mutter's design language or not.

[IsaacMarovitz]

are you planning to support Client-side decoration (CSD) just for wayland ?

Really it would be just adding CSD support for Wayland on Mutter specifically.

X11 supports SSD, and the only major Wayland compositor to not support SSD is Mutter.

[maxkatz6]

I am going to close this PR as it's not active and more work is pending from our side (i.e. CSD).
If you want to add any comments on the feature in general, please add them to this issue instead #1243