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

Our own backend for Wayland #1243

Open
kekekeks opened this issue Oct 22, 2017 · 31 comments
Open

Our own backend for Wayland #1243

kekekeks opened this issue Oct 22, 2017 · 31 comments
Assignees
Milestone

Comments

@kekekeks
Copy link
Member

kekekeks commented Oct 22, 2017

There are way too many limitations and tradeoffs that GTK/GDK have to support both of them, while not allowing us to do things that we want to do. Notable examples are separate-thread rendering (we have to use our own X11 connection to do that) and issues with absolute window positioning on Wayland (Wayland has xdg_surface_set_window_geometry which isn't used by GTK for some reason which leads to our popups being broken, we are forcing GTK to use X11 backend because of that).

There are some major caveats on that way:

  1. System dialogs (open/save file, folder selection, etc). We need to either still load GTK or have them out-of-proc somehow. The out-of-proc way will cause issues with making dialogs modal to the parent window on X11
  2. Input methods. Right now we are relying on GTK do support them
  3. Client-side window decorations. Some of the wayland shells are requiring applications to draw window frame, title and buttons, we need to support that somehow
@kekekeks kekekeks added this to the 1.0 milestone Oct 22, 2017
@martindecker
Copy link

Does "Our own backends for X11/Wayland " mean , you plan to write (more) code to interact with X11 ? I think, because Wayland is the future, it is not necessary to support X11 anymore. Keep it simple and only support Wayland. But I am not expert regarding this question, currently I am a WPF developer.

@kekekeks
Copy link
Member Author

Wayland haven't yet reached the feature parity with X11 and judging from their mailing list will never do so, because some features aren't implemented on purpose. X11 will also be more widespread for a half a decade, at least.

@kekekeks
Copy link
Member Author

kekekeks commented Mar 5, 2018

Shower thought: GTK is not, in fact, a "native" UI toolkit for Linux. Some popular distros are using KDE and Qt. So our dependency on GTK isn't free. Our file dialogs also don't look native everywhere.

So we should use libX11/libxcb for UI and separate backend system for file dialogs, that should support:

  • GTK2/3
  • Qt 3/4/5
  • our own managed implementation that doesn't depend on anything

@kekekeks kekekeks modified the milestones: 1.0, 0.7.0 (Beta 2) Mar 5, 2018
@kekekeks
Copy link
Member Author

kekekeks commented Mar 5, 2018

According to https://lists.freedesktop.org/archives/wayland-devel/2017-September/034967.html wayland doesn't support dpi awareness. Great.

@jkoritzinsky
Copy link
Collaborator

It looks like there's support on the Wayland side (and in Weston) as of 1.2, but there isn't support in the XWayland front end.

https://github.com/wayland-project/weston/blob/1a2adfedea74ae264eca7d4b8cbe6d1f04e552bf/man/weston.ini.man#L415

@kekekeks
Copy link
Member Author

kekekeks commented Mar 5, 2018

Yep, wl_surface::set_buffer_scale seems to be the way for per-window scaling factors

@grokys grokys modified the milestones: 0.7.0, 0.8.0 Jul 5, 2018
@grokys grokys modified the milestones: 0.8.0, 0.9 Apr 5, 2019
@iMonZ
Copy link

iMonZ commented Aug 25, 2021

Shower thought: GTK is not, in fact, a "native" UI toolkit for Linux. Some popular distros are using KDE and Qt. So our dependency on GTK isn't free. Our file dialogs also don't look native everywhere.

So we should use libX11/libxcb for UI and separate backend system for file dialogs, that should support:

* GTK2/3

* Qt 3/4/5

* our own managed implementation that doesn't depend on anything

So xcb doesn't work on modern systems.
Maybe dropping gtk2 support would help with the problems.
But full Wayland support without X11 or XWayland or xcb should be on the roadmap.
Ubuntu LTS will switch to Wayland in 22.04 and most other popular distros already switched to Wayland.
And most feature aren't implemented in Wayland for security reason, so yes it's on purpose.

It would be great if the support in AvaloniaUI would be there until Ubuntu will switch in the LTS

@jgcodes2020
Copy link
Contributor

Shower thought: GTK is not, in fact, a "native" UI toolkit for Linux. Some popular distros are using KDE and Qt. So our dependency on GTK isn't free. Our file dialogs also don't look native everywhere.

So we should use libX11/libxcb for UI and separate backend system for file dialogs, that should support:

* GTK2/3

* Qt 3/4/5

* our own managed implementation that doesn't depend on anything

File dialogs can be handled via desktop portals: https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.FileChooser

@maxkatz6
Copy link
Member

maxkatz6 commented Jun 7, 2022

@jgcodes2020 yes, and it was #8217

@affederaffe affederaffe mentioned this issue Jun 16, 2022
36 tasks
@maxkatz6 maxkatz6 modified the milestones: 0.9, 11.0 Jun 19, 2022
@maxkatz6 maxkatz6 modified the milestones: 11.0, 11.x Mar 9, 2023
@microhobby
Copy link
Contributor

Hey, my dear Avalonia maintainers, let me say that this is important. Some users that are using Avalonia for embedded system does feel more comfortable having a desktop environment than using framebuffer or DRM. So, for embedded some machines does not support X11 anymore, only Wayland and Weston. "XWayland can still be used" may some argue. Yeah, but in some scenarios Xwayland is not supported and also is hard to set openGL ES for Xwayland, so, no HW acceleration for this users...

@timunie
Copy link
Contributor

timunie commented May 22, 2023

Wayland is planned afaik and the preparation work where we need breaking changes is already in progress. In the 11.x time frame we hope to be able to add wayland support. @affederaffe already did a great job on this backend.

@iMonZ
Copy link

iMonZ commented Nov 19, 2023

Wayland is planned afaik and the preparation work where we need breaking changes is already in progress. In the 11.x time frame we hope to be able to add wayland support. @affederaffe already did a great job on this backend.

Hey
any news on that?

@ratin3
Copy link

ratin3 commented Mar 31, 2024

Gentlemen, I am working with Zynq / embedded os like Petalinux, was wondering what components I will need to support Avalonia UI and .Net framework that Avalonia is based on. I would like to avoid Xorg if possible. Thanks

@maxkatz6 maxkatz6 changed the title Our own backends for X11/Wayland Our own backend for Wayland Apr 25, 2024
@jindongjie
Copy link

Gentlemen, I am working with Zynq / embedded os like Petalinux, was wondering what components I will need to support Avalonia UI and .Net framework that Avalonia is based on. I would like to avoid Xorg if possible. Thanks先生们,我正在使用 Zynq / 嵌入式操作系统,例如 Petalinux,我想知道我需要哪些组件来支持 Avalonia 所基于的 Avalonia UI 和 .Net 框架。如果可能的话,我想避免Xorg。谢谢

Just use LinuxFrameBuffer, ther are tutorial in avalonia document.

@amayra
Copy link

amayra commented Sep 14, 2024

so Wayland support is officially dead ?

thanks gnome devs

@maxkatz6
Copy link
Member

so Wayland support is officially dead ?

It's not.

@jindongjie
Copy link

so Wayland support is officially dead ?

It's not.
So,in future we can use wayland backend without manually install nuget pkg?

@Haltroy
Copy link

Haltroy commented Sep 14, 2024

Can't we just fallback to X11 (XWayland in this case) in GNOME and use Wayland on others that do support what we need?
This way, we can still have a partial support on Wayland until we figure out something for GNOME.
— A KDE Plasma Wayland Session Hyprland (yes I am one of those people now) User

@maxkatz6
Copy link
Member

So,in future we can use wayland backend without manually install nuget pkg?

That's the plan. We are not working on wayland support right now, but we didn't give up on the idea to support it for 11.x or 12.0 release.

@Haltroy I would ping @kekekeks or @jmacato to answer that.

@TheArcaneBrony
Copy link

Would be nice if Wayland support was prioritised, especially given I no longer have a way to reach out for support when things don't work with xwayland.

@jgcodes2020
Copy link
Contributor

Given that CSD is the primary blocker for Wayland support, is there a tracker issue or potential API design work that has been done for it?

@kekekeks
Copy link
Member Author

kekekeks commented Oct 20, 2024

The plan is to keep CSD completely hidden from the user code and implement them as a combination of platform backend code and our compositor internals. It would be either a fake TopLevel that renders to the main wl_surface with client area being rendered into wl_subsurface, or some way to overlay multiple TopLevel's into the same composition target instance.

@Haltroy
Copy link

Haltroy commented Oct 20, 2024

Wait I'm confused.

CSD ("client-side decorations ") is what GNOME uses which render the title bar (Avalonia's "ExtendClientAreaChromeHints"). SSD (server-side decorations") is what KDE/Qt uses which lets the compositor to draw the title bar. Source
So the CSD stuff should be already implemented (since it's a GNOME thing and usually GNOME's things are applied to everyone but not vice-versa which is the case of my comment). The thing that you should use for drawing "ExtendClientAreaChromeHints" should be CSD (in my opinion), correct me if I'm wrong. If we don't want to extend to titlebar we don't set this value to anything and use the default which is the case where you would use SSD.

How about this: use CSD completely. Make a default titlebar for Avalonia windows for normal title bar and hide it if this setting is set to a different value. This way you don't have to wait GNOME another millennium to implement SSD to Mutter.

I have no idea how this works or might get it wrong so if I do please correct me. Also is there anything that's blocking Wayland support for Avalonia?

@kekekeks
Copy link
Member Author

is what GNOME uses which render the title bar

GNOME does not draw the titlebar, GNOME forces wayland applications to draw their own titlebars. That's not the case for Windows, macOS, X11 and most of Wayland compositors.

Avalonia doesn't currently provide its own titlebar and attempting to put one into Window template will break app expectations of full ClientSize being available to them.

Implementing CSD in a way that's consistent with app expectations on other platforms is doable, but requires work that's currently not planned for the next months.

@Haltroy
Copy link

Haltroy commented Oct 21, 2024

is what GNOME uses which render the title bar

GNOME does not draw the titlebar, GNOME forces wayland applications to draw their own titlebars. That's not the case for Windows, macOS, X11 and most of Wayland compositors.

That's what I meant. Sorry for confusion.

Avalonia doesn't currently provide its own titlebar and attempting to put one into Window template will break app expectations of full ClientSize being available to them.

Implementing CSD in a way that's consistent with app expectations on other platforms is doable, but requires work that's currently not planned for the next months.

No just implement that on Linux Wayland. Or even better, just show it on GNOME Wayland (detect Mutter, detect that it's on Wayland and show a simple title bar). If the window has that ExtendToChromeSomethingSomething then just don't show that title bar. On anything else use SSD and let KWin etc. to draw the tite bar for you.

I mean it's not a clean solution but everyone knows that GNOME won't add SSD support to Mutter in the future and waiting on that promise will halt Avalonia's Wayland support.

You already can make a custom title bar on Avalonia that has the same functions as a normal one. And not just that you also can create window borders that works. I'll make a template for that in the future if anyone wants to use it (and for myself).

@TheArcaneBrony
Copy link

Couldn't Avalonia report a smaller ClientSize when drawing a title bar?

@kekekeks
Copy link
Member Author

Couldn't Avalonia report a smaller ClientSize when drawing a title bar?

That would mean implementing titlebar in some horrible way instead of just defining it as a normal templated control. Would also still require wl_subsurface for actual content.

There are no hard blockers, just no resources are currently allocated for wayland support.

@kekekeks
Copy link
Member Author

I could perhaps have worked on it in my spare time, but it would require enthusiasm and it's hard to have enthusiasm for a tech that still cant run my primary desktop session in 2024 because of various questionable design decisions.

@amayra
Copy link

amayra commented Oct 22, 2024

I could perhaps have worked on it in my spare time, but it would require enthusiasm and it's hard to have enthusiasm for a tech that still cant run my primary desktop session in 2024 because of various questionable design decisions.

just ignore Gnome

they always sabotage any new wayland protocols. Just keep it as drafts for more than 4 years

just like how game developers ignore mac OS

@amayra
Copy link

amayra commented Oct 22, 2024

Would be nice if Wayland support was prioritised, especially given I no longer have a way to reach out for support when things don't work with xwayland.

ryujinx user ?

@TheArcaneBrony
Copy link

something ryujinx? i dont, no.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.