Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wayland backend #8352

Closed
wants to merge 0 commits into from
Closed

Wayland backend #8352

wants to merge 0 commits into from

Conversation

affederaffe
Copy link
Contributor

@affederaffe affederaffe commented Jun 16, 2022

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 run
This PR is still WIP, help is greatly appreciated.

What currently works:

  • Windowing:
    • Window creation
    • Window modes: Normal, Maximized, Fullscreen
    • Resizing
    • Popups
    • File Dialogs (native + managed fallback)
    • Tray icons
    • Client Side Decorations
  • Keyboard:
  • Mouse:
    • Basic handling
    • Scrolling
    • Theme cursors
    • Custom cursors
    • Animated cursors
  • Touch:
    • Basic handling
  • Data sharing:
    • Clipboard:
      • Reading
      • Writing
    • DND
  • Rendering:
    • Backends:
      • EGL
      • FrameBuffer
    • Modes:
      • Deferred
      • Immediate
      • Composition

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 (?)

@kekekeks
Copy link
Member

If Wayland bindings are stable, I'll publish a packaged version on nuget

@kekekeks
Copy link
Member

@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.

@kekekeks
Copy link
Member

Ah, you were already trying to enable them, nvm

@affederaffe
Copy link
Contributor Author

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.

@affederaffe
Copy link
Contributor Author

@kekekeks Any plans on releasing NWayland on NuGet?

@affederaffe affederaffe marked this pull request as ready for review August 20, 2022 19:52
Copy link
Member

@jmacato jmacato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

@kekekeks
Copy link
Member

@jmacato you need to use a desktop environment that supports server decorations. Basically not GNOME.

@jmacato
Copy link
Member

jmacato commented Aug 21, 2022

@affederaffe im still getting the same error in gnome on the latest commit:
image

@kekekeks
Copy link
Member

Yes, your desktop environment needs to support Server Side Decorations. Please, check with desktop environment that supports zxdg_decoration_manager_v1

@affederaffe
Copy link
Contributor Author

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.

@jmacato
Copy link
Member

jmacato commented Aug 22, 2022

image
This is wild :D but it seems like that we need a way to add CSD on windows that didnt specify it. I know GNOME is a bit thickheaded but it's a major DE that we cannot ignore.

@jmacato
Copy link
Member

jmacato commented Aug 24, 2022

@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:

image

Some windows still doesnt have CSD for some reason, like the DevTools window for example

@affederaffe affederaffe changed the title [WIP] Wayland backend Wayland backend Aug 24, 2022
@jmacato
Copy link
Member

jmacato commented Aug 27, 2022

@affederaffe @kekekeks im curious, is it possible to make a RenderTimer that is synchronized to the Compositor's refresh rate?

@kekekeks
Copy link
Member

kekekeks commented Aug 27, 2022

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.

@jmacato
Copy link
Member

jmacato commented Aug 28, 2022

@kekekeks by global variables you mean the inherited Clocks?

@kekekeks
Copy link
Member

Yes, UI thread animations expect to have some global clock to function.

@jmacato
Copy link
Member

jmacato commented Aug 28, 2022

@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

@kekekeks
Copy link
Member

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.

@Conan-Kudo
Copy link

You might want to look into libdecor for handling SSD-less compositors (basically just Mutter from GNOME).

@kekekeks
Copy link
Member

kekekeks commented Sep 9, 2022

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.

@jmacato
Copy link
Member

jmacato commented Sep 9, 2022

@kekekeks i like having our own CSD implementation better tbh. That way users can modify it so without much fuss.

Copy link
Member

@jmacato jmacato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

I cant seem to build this in a fresh clone

@affederaffe
Copy link
Contributor Author

@jmacato You need to add
<ItemGroup Label="InternalsVisibleTo"> <InternalsVisibleTo Include="NWayland.Protocols.Plasma, PublicKey=$(AvaloniaPublicKey)" /> <InternalsVisibleTo Include="NWayland.Protocols.Wlr, PublicKey=$(AvaloniaPublicKey)" /> </ItemGroup>
for the time being, that'll be fixed once the bindings are published on NuGet.

@jmacato
Copy link
Member

jmacato commented Oct 10, 2022

@affederaffe im getting this error now as well, fixed the public sigs though with your comment
image

@affederaffe
Copy link
Contributor Author

I opened a PR with my fixes for NWayland here.

  • Should Copy/Paste decode entered unicode codes? As far as I know hard-coded charachters are decoded correctly and only those entered by the user are escaped, just like with X11.
  • The framerate can easily be unlocked once there's a solution for brushes ticking in ResourceDictionaries as discussed above.
  • This seems to be an issue with shared contexts with the EGL backend and doesn't work on X11 either. I can try to fix this, though I have no knowledge on this so I'd appreciate a little help.

@jmacato
Copy link
Member

jmacato commented Oct 21, 2022

@affederaffe im waiting for @kekekeks to review your PR on NWayland's repo. After he publishes the nuget we can get this PR merged :)

@jmacato
Copy link
Member

jmacato commented Nov 5, 2022

@affederaffe Seems like the FPS overlay is not displaying correctly on Gnome?
image

I'm also noticing some issues with mouse clicks being lost somehow, happens when i open DevTools as well

@squidink7
Copy link

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
image
I also needed to remove the InternalsVisibleTo lines in the NWayland project file or no apps would build.
Very nice work though, other than that everything was working well as far as I saw!

@robloo
Copy link
Contributor

robloo commented Feb 7, 2023

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.

@kekekeks kekekeks added this to the 11.0 milestone Feb 7, 2023
@timunie
Copy link
Contributor

timunie commented Mar 8, 2023

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

@affederaffe
Copy link
Contributor Author

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.

@timunie
Copy link
Contributor

timunie commented Mar 8, 2023

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.

@kekekeks
Copy link
Member

kekekeks commented Mar 9, 2023

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.

@zoujiaqing
Copy link

Everyone is looking forward to the Wayland feature! I hope it can be included in the new version!

@jgcodes2020
Copy link
Contributor

jgcodes2020 commented Mar 14, 2023

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.

@nicola36631
Copy link
Contributor

@affederaffe is there some way the community can help with this PR? What is still missing/not working at the moment?

@kekekeks
Copy link
Member

kekekeks commented Apr 5, 2023

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.

@jgcodes2020
Copy link
Contributor

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 xdg-decoration support).

@kekekeks
Copy link
Member

kekekeks commented Apr 6, 2023

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.

@nicola36631
Copy link
Contributor

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 xdg-decoration support).

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?

@Doomsdayrs
Copy link

Closed??

@zoujiaqing
Copy link

Wow...

@ChristophSchmidpeter
Copy link

affederaffe force-pushed the master branch from a127993 to f0e0366

@Doomsdayrs The PR appears to have been automatically closed by the force-push

@robloo
Copy link
Contributor

robloo commented Apr 24, 2023

Hopefully this is just closed because the strategy was changed a bit for 11.0

  1. Pull out the core changes it needs and get those in for 11.0
  2. Finish and merge this in the 11.x series in a separate PR

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.

@affederaffe
Copy link
Contributor Author

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.

@affederaffe affederaffe mentioned this pull request May 28, 2023
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Chrome OS? Our own backend for Wayland