Wayland backend #8352
Wayland backend #8352
Conversation
|
If Wayland bindings are stable, I'll publish a packaged version on nuget |
|
@affederaffe I believe we already have rudimentary CSD that are used for Win32 backend. Resize-grips are missing but other than that they are more or less usable even with X11. |
|
Ah, you were already trying to enable them, nvm |
|
Neither resize nor move seem to be currently implemented and the X11 backend doesn't support CSD either, so I thought I'd disable them for now. |
|
@kekekeks Any plans on releasing NWayland on NuGet? |
There was a problem hiding this comment.
@affederaffe @kekekeks this doesnt seem to work on GNOME coz i got this message
Unhandled exception. System.NotSupportedException: Unable to find zxdg_decoration_manager_v1 in the registry
at Avalonia.Wayland.WlRegistryHandler.Bind[T](IBindFactory`1 factory, String interface, Int32 version) in /var/home/strix/RiderProjects/AvaloniaM/src/Linux/Avalonia.Wayland/WlRegistryHandler.cs:line 59
at Avalonia.Wayland.WlRegistryHandler.BindRequiredInterface[T](IBindFactory`1 factory, String interface, Int32 version) in /var/home/strix/RiderProjects/AvaloniaM/src/Linux/Avalonia.Wayland/WlRegistryHandler.cs:line 49
at Avalonia.Wayland.AvaloniaWaylandPlatform..ctor(WaylandPlatformOptions options) in /var/home/strix/RiderProjects/AvaloniaM/src/Linux/Avalonia.Wayland/AvaloniaWaylandPlatform.cs:line 37
at Avalonia.AvaloniaWaylandPlatformExtensions.<>c__0`1.<UseWayland>b__0_0() in /var/home/strix/RiderProjects/AvaloniaM/src/Linux/Avalonia.Wayland/AvaloniaWaylandPlatform.cs:line 156
at Avalonia.Controls.AppBuilderBase`1.Setup() in /var/home/strix/RiderProjects/AvaloniaM/src/Avalonia.Controls/AppBuilderBase.cs:line 280
at Avalonia.Controls.AppBuilderBase`1.SetupWithLifetime(IApplicationLifetime lifetime) in /var/home/strix/RiderProjects/AvaloniaM/src/Avalonia.Controls/AppBuilderBase.cs:line 148
at Avalonia.ClassicDesktopStyleApplicationLifetimeExtensions.StartWithClassicDesktopLifetime[T](T builder, String[] args, ShutdownMode shutdownMode) in /var/home/strix/RiderProjects/AvaloniaM/src/Avalonia.Controls/ApplicationLifetimes/ClassicDesktopStyleApplicationLifetime.cs:line 208
at ControlCatalog.NetCore.Program.Main(String[] args) in /var/home/strix/RiderProjects/AvaloniaM/samples/ControlCatalog.NetCore/Program.cs:line 103
cd ./src/Linux/NWayland/src/NWayland.CodeGen && dotnet run should be updated to cd ./src/Linux/NWayland/src/NWayland.Scanner && dotnet run
|
@jmacato you need to use a desktop environment that supports server decorations. Basically not GNOME. |
|
@affederaffe im still getting the same error in gnome on the latest commit: |
|
Yes, your desktop environment needs to support Server Side Decorations. Please, check with desktop environment that supports |
|
Decorations seem to work on Gnome now, though I noticed that popups and drag&drop are completely broken on it, even though they work perfectly fine on KDE. |
|
|
|
@affederaffe this is so amazing :D i can do DnD on linux now :D thanks so much for this effort! btw, some more bug reports if you dont mind:
Some windows still doesnt have CSD for some reason, like the DevTools window for example |
|
@affederaffe @kekekeks im curious, is it possible to make a RenderTimer that is synchronized to the Compositor's refresh rate? |
|
You can ask the compositor to send you a callback when it thinks that's a good idea to start rendering a new frame for a particular wl_surface. However for that to work each window would have its own render timer. While being possible to refactor our rendering to use multiple render timers, I'm afraid the UI thread animations like their global variables a bit too much, so we can't do that. |
|
@kekekeks by global variables you mean the inherited Clocks? |
|
Yes, UI thread animations expect to have some global clock to function. |
|
@kekekeks that can be refactored yes, inherently we only need a way to hand over some kind of timer to the clocks. each window/surface can have one timer each and it should work fine |
Animations can tick on brushes in resource dictionaries that are shared by multiple windows. |
|
You might want to look into libdecor for handling SSD-less compositors (basically just Mutter from GNOME). |
|
Last time I've checked libdecoration required glib and wasn't really thread safe, which is important because Avalonia does event handling/layout and rendering on different threads. |
|
@kekekeks i like having our own CSD implementation better tbh. That way users can modify it so without much fuss. |
|
@jmacato You need to add |
|
@affederaffe im getting this error now as well, fixed the public sigs though with your comment |
|
I opened a PR with my fixes for NWayland here.
|
|
@affederaffe im waiting for @kekekeks to review your PR on NWayland's repo. After he publishes the nuget we can get this PR merged :) |
|
@affederaffe Seems like the FPS overlay is not displaying correctly on Gnome? I'm also noticing some issues with mouse clicks being lost somehow, happens when i open DevTools as well |
|
I just tried this on Arch Linux KDE, and found issues related to maximising. The window would only maximise to a small portion of the actual screen size, and would become even smaller when any other window was focused |
|
Hope there is discussion with the core team on this and a plan for merging. Really should have been merged in before the RC in my opinion (so by preview 5). It needs a chance for good testing before release. |
|
Hey @affederaffe , I want to reach out for you as 11.0 is going to be closer and this PR is a really huge PR. We really appreciate your efforts and it is on our todo-list to get it merged. But most likely it will not be included in 11.0, as 11.0 has already a lot of new stuff inside. We plan to add this feature in a 11.x release after the major 11.0 bugs are ironed out. I hope for your understanding 💐 Happy coding Tim |
|
I completely understand, also there are still some bugs left I haven't had the time to fix yet and probably won't in the near future, so it's definitely for the better. Still, I plan to work on this PR eventually, it is not abandoned. |
|
Okay, so we are on the same route. That's great. I think it is a good idea to merge master as you already do it in order to not get too much out of sync. Anything else can be done later 👍 Have a nice day. |
|
To be clear: we are planning to extract any changes to Avalonia core libs from this PR and merge them before 11.0. That way the rest of Wayland support could be merged later in 11.x. |
|
Everyone is looking forward to the Wayland feature! I hope it can be included in the new version! |
|
If it's helpful, here's an alternative Wayland library: https://github.com/X9VoiD/WaylandSharp It handles the generation as a code-analysis stage, so you don't have to manually run the scanner to generate the API. |
|
@affederaffe is there some way the community can help with this PR? What is still missing/not working at the moment? |
|
Note that the way CSD are implemented kinda interferes with Window's Width/Height controlling the client area size. So it probably can't be merged as is, proper CSD would require some major changes in either TopLevel or composition code. |
Proper CSD might be worth splitting into a separate PR, since there are already a lot of changes here. All that matters for a Wayland backend is that it runs on GNOME (which has no current or planned |
|
Gnome is pretty much the only "very special child" that needs us to implement CSD. Without CSD it won't show any window frame. We could merge Wayland without CSD and ignore gnome for now since it would enable some embedded device scenarios that are running fullscreen anyways. |
I think that supporting GNOME and KDE Plasma (best looking) and XFCE (most lightweight) is quite important as they are "the top dogs" of desktop environments on Linux. Perhaps improving Client Side Decorations is an issue that can be moved to the 11.x milestone? |
|
Closed?? |
|
Wow... |
@Doomsdayrs The PR appears to have been automatically closed by the force-push |
|
Hopefully this is just closed because the strategy was changed a bit for 11.0
If this was closed because it is no longer developed that is most unfortunate. It should have been merged as-is and provided a good base for everyone to test and patch from. 95% was more than OK in my opinion for a previously unsupported backend. |
|
I'm just starting to rebase my patches onto master and I decided it's easier to do so on a new branch. That comes with the advantage of a clean master branch and a feature branch, like it should've been from the start. The wayland backend still needs some work and I don't have that much time in the coming weeks, after that I do though. |
What does the pull request do?
Add a Wayland backend for Linux.
There hasn't been any activity on the previous PR, which is why I'm opening one on my own.
At the moment, you have to manually generate the Wayland bindings because I haven't figured out how to do so on build:
cd ./src/Linux/NWayland/src/NWayland.Scanner && dotnet runThis PR is still WIP, help is greatly appreciated.
What currently works:
What is the current behavior?
Currently, 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.
Checklist
Breaking changes
Some projects where moved to the Linux solution.
Obsoletions / Deprecations
None
Fixed issues
Fixes #1243
Fixes #2338 (?)