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

Add support for the Wayland display server #990

Closed
akien-mga opened this issue Jun 2, 2020 · 53 comments · Fixed by godotengine/godot#86180
Closed

Add support for the Wayland display server #990

akien-mga opened this issue Jun 2, 2020 · 53 comments · Fixed by godotengine/godot#86180

Comments

@akien-mga
Copy link
Member

akien-mga commented Jun 2, 2020

Describe the project you are working on:
Godot's platform ports.

Describe the problem or limitation you are having in your project:
None directly as X11 still works decently on recent Linux distros, but we need to add support for the more modern Wayland display server eventually.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Wayland is a newer, more modern display server that can be used on Linux and likely some BSD-derived OSes too (now or in the future).

Many Linux distros / DEs now run on Wayland by default, and Godot only works thanks to the xwayland compatibility layer.

Having builtin Wayland support will give us access to a much cleaner API as well as more advanced features for window management, etc.

Supersedes godotengine/godot#576 - see discussion there for relevant technical details.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
I'm not an expert on Wayland so I'll let others fill in and explain what are the gains we can expect from having built-in Wayland support.

From a technical implementation point of view, the following points are important:

  • Implement Wayland support was intentionally kept on hold until we would split the OS and DisplayServer components, so that we can have a Linux/*BSD platform port with more than one DisplayServer implementations. This has now been done in the master branch, and thus Wayland support can be implemented for Godot 4.0. There's no intention to backport it to earlier releases.
  • There are many issues on all platforms following the DisplayServer split and implementation of multi-window support ([TRACKER] DisplayServer, Window & UI issues godot#37734). It is recommended to wait for most of those issues to be fixed before starting implementing a new DisplayServer (though help is very welcome from Wayland aficionados to first fix the outstanding X11 issues after this refactoring).
  • Wayland and X11 support should be implemented in a way that works with a single Godot binary, i.e. the relevant libraries should probably be dlopen-ed so that the same binary can be used on systems with only X11, only Wayland, or both installed.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
No.

Is there a reason why this should be core and not an add-on in the asset library?:
This can only be done in core.

@akien-mga
Copy link
Member Author

Relevant PRs with initial Wayland implementation but that pre-dated the OS/DisplayServer split and thus couldn't be merged:

godotengine/godot#23426 (@toger5)
godotengine/godot#27463 (@ddevault)

@ssokolow
Copy link

ssokolow commented Jun 2, 2020

Having builtin Wayland support will give us access to a much cleaner API as well as more advanced features for window management, etc.

Most notably for me, denying Wayland applications un-privileged access to the "confuse the window manager about whether this resolution change is permanent enough that windows should be repositioned to keep them within the bounds of the desktop" API. (i.e. X11's decision that games and control panels use the same resolution-changing API that's not tied to the lifetime of a window.)

@Calinou
Copy link
Member

Calinou commented Jul 31, 2020

@ssokolow Godot never attempts to change the screen resolution, so this shouldn't be an issue in the current state of things. Still, Wayland has many other benefits.

@ssokolow
Copy link

ssokolow commented Jul 31, 2020

Oh, certainly. It's more that so many other games screw that up, or misbehave when they discover that I've removed standard resolutions like 800x600 from the list of valid fullscreen resolutions (to prevent them from screwing it up) that it's by far the most noteworthy Wayland feature for me on a machine which is going to be playing games.

(eg. The game Dungeons of Dredmor will refuse to accept any windowed resolution that's not a valid fullscreen resolution. I've been meaning to write an SDL LD_PRELOAD hook for ages to lie about the list of valid fullscreen resolutions and then force windowed mode if one of the injected ones is chosen.)

@carwyn
Copy link

carwyn commented Oct 25, 2020

Earlier this week I read the updates in the X11 display server progress report article which does mention Wayland being "still not widely used".

Meanwhile today in this article: It's Time To Admit It: The X.Org Server Is Abandonware there are various snippets that give an idea of current state of play for Wayland and X11. Notably they mention that Ubuntu 21.04 may well be the version that defaults back to Wayland.

Currently Fedora, RHEL since version 8 and Debian since version 10 I believe all default to Wayland over X11. With Ubuntu possibly joining them next year I'm not sure that "still not widely used" is entirely accurate :)

Posting to provide the second article above (which has links to relevant conversations) as evidence really.

@Calinou
Copy link
Member

Calinou commented Oct 25, 2020

Currently Fedora, RHEL since version 8 and Debian since version 10 I believe all default to Wayland over X11. With Ubuntu possibly joining them next year I'm not sure that "still not widely used" is entirely accurate :)

Keep in mind that on NVIDIA graphics cards, those distributions' installers or session managers will often fall back to X11 by default.

Also, with WINE still not having official native Wayland support, Linux gamers are likely to keep using X11 for a while. (WINE gaming makes for a large share of popular games currently playable on Linux after all.)

@pouleyKetchoupp
Copy link

Just adding actual data to the conversation. It's great that things are progressing, but the current state seems to be that most gamers are on X11:
https://www.gamingonlinux.com/users/statistics#SessionType-top

So I don't think it's exaggerated to state that Wayland is not widely used at the moment. That said, now that the X11 display server is in a better shape, contributions for Wayland support are welcome :)

@carwyn
Copy link

carwyn commented Oct 25, 2020

Just adding actual data to the conversation. ...
https://www.gamingonlinux.com/users/statistics#SessionType-top

The distribution statistics in there are worth looking at too with most being Ubuntu based. If Ubuntu does indeed jump with 21.04 then there would be a fairly big swing fairly quickly potentially.

Either way, more than happy to help test/debug Wayland support :)

@Calinou
Copy link
Member

Calinou commented Oct 25, 2020

If Ubuntu does indeed jump with 21.04 then there would be a fairly big swing fairly quickly potentially.

Most Ubuntu users stick to LTS versions nowadays. Non-LTS Ubuntu versions are becoming increasingly less popular over time, especially since getting recent applications working on LTS distributions is now easier than it has ever been.

Therefore, we'd have to wait until Ubuntu 22.04 is released1 to see any substantial difference.

Footnotes

  1. And keep in mind the upgrade for existing LTS users is only available once the first point release is out. That means waiting until July 2022 🙂

@dvergeylen
Copy link

dvergeylen commented Jan 21, 2021

Just adding actual data to the conversation. It's great that things are progressing, but the current state seems to be that most gamers are on X11:
https://www.gamingonlinux.com/users/statistics#SessionType-top

Quiet funny, 2 users reported they use Cinnamon as their Wayland Desktop although Cinnamon doesn't support Wayland (see here and here).

I would love to see native Wayland support but I have to admit nVidia recently submitted patches to support hardware accelerated rendering under XWayland, with performances "roughly on-par with native X11".

Yet another argument to say that Wayland support is not that critical by now 🤷. Probably at least not before godotengine/godot#37734 .

@dvergeylen
Copy link

If Ubuntu does indeed jump with 21.04 then there would be a fairly big swing fairly quickly potentially.

Ubuntu 21.04 will indeed default to Wayland, paving the way for 22.04 LTS. Nvidia users will still default to Xorg for now ("but hopefully that situation will be resolved before the LTS") 😃.

@Sslaxx
Copy link

Sslaxx commented Apr 10, 2021

https://www.gamingonlinux.com/2021/04/xwayland-work-for-hardware-accelerated-nvidia-support-has-been-merged-in - sounds like it'll be ready for Nvidia users on Ubuntu by 21.10 (assuming they don't release a point update for 21.04 with it), so high probability for 22.04.

@ryleu
Copy link

ryleu commented Sep 2, 2021

I’m currently running ubuntu 21.04 and it defaults to Wayland.

@Calinou Calinou modified the milestones: 4.0, 4.x Sep 2, 2021
@CrezyDud
Copy link

I’m currently running ubuntu 21.04 and it defaults to Wayland.

how?
is it implemented?
doesn't for me.

WE NEED WAYLAND SUPPORT
XWAYLAND IS A BUGGY MESS
PLEAAEEAEAEAEEAEAEAESE

@Calinou
Copy link
Member

Calinou commented Nov 11, 2021

how? is it implemented? doesn't for me.

Godot 3.x and master run on Wayland via XWayland, as Godot doesn't have native Wayland support yet. Native Wayland support is unlikely to be added to 4.0 due to time constraints, but it may be added in a future 4.x release.

If you run into issues on XWayland but not native X11, please report them to the XWayland developers first. If (and only if) it turns out to be something that can't be fixed at a XWayland level, please report them on the main Godot repository.

@iMonZ

This comment has been minimized.

@Calinou

This comment was marked as resolved.

@Riteo
Copy link

Riteo commented Jan 14, 2022

Hi! I'd be glad to implement this. I already got a very basic working prototype.

EDIT: Just to be clear, by very basic I mean that it can resize itself properly in single-window mode and that it can (as of very, very recently) handle just pointer motions and its left click. I started it just a few days ago. Sorry for any misunderstanding that I might have caused.

@dvergeylen
Copy link

Hi! I'd be glad to implement this. I already got a very basic working prototype.

Would you mind sharing a link? 🙏

@Riteo
Copy link

Riteo commented Feb 19, 2022

@KiwwiPity I see, I thought it was some protocol issue. Weird though, I thought that Wayland used libinput for input handling and all old drivers should've worked fine.

@ryleu
Copy link

ryleu commented Feb 19, 2022

I personally have had no issues with a tablet stylus (my laptop has built-in support, it’s not a normal touchscreen stylus) on Wayland. Both Krita and Rnote work perfectly with it. This also seems like a relatively small thing for Godot, considering that the vast majority of games don’t need a stylus. For the stylus games, they can just use X.

I think the biggest blocker for Wayland games is the lack of support on older NVIDIA cards. For example: my GTX 780.

@azur-wolve
Copy link

@Riteo Huion tablets have not official support for Linux, the drivers I use are community made, so the problem could be there.

@snoopdouglas
Copy link

Will work on this also implement HiDPI awareness on Linux?

@Riteo
Copy link

Riteo commented Dec 29, 2022

@snoopdouglas this is definitely planned, but Wayland has a really weird approach with scaling that will probably require some core changes (not sure, I'm not a rendering person).

Basically you get a window which is, for example assuming scale 2, half the resolution but twice the size. How do you get crisp graphics then, you might ask? Through some sort of "supersampling", by sending a buffer that's twice the resolution (but with the same half-sized coordinate system).

I don't know if I've been clear enough, but this requires something very similar (AFAIK) to the text supersampling option in Godot, and doesn't sound very trivial to implement properly.

@HalanoSiblee

This comment was marked as off-topic.

@Calinou
Copy link
Member

Calinou commented Apr 18, 2023

@HalanoSiblee Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.

@azur-wolve
Copy link

@HalanoSiblee Wayland still very problematic in general, even XFCE lacks wayland support until now.
Also those Linux users that own an Nvidia GPU would have problems with Wayland, even if it wasn't from Godot side.
So its a domain problem, more than a Godot problem, properly speaking.
For now it looks like its almost impossible gaming properly or any kind of real-time graphics with Nvidia + Wayland.
If someone knows how fix that just shoot.

@sonic2kk
Copy link

Supposedly KDE Plasma Wayland works for Nvidia users (with a handful of remaining limitations, see the Nvidia section of the Plasma Wayland showstoppes), but AMD and Intel GPUs work fine for gaming on Wayland. I have been using Plasma Wayland for gaming for well over a year on my 5700XT, and on a couple of Intel laptops, specifically for a mixed-scaling and mixed-refresh-rate setup.

Some desktop environments, such as KDE, are moving to Wayland as the default. Of course, distributions can still override this like Ubuntu do/did with GNOME. Native Wayland support may gain more interest as a result of this though, mainly for mixed-scale users where KDE's X11 scaling option doesn't help, and XWayland apps are blurry. Other DEs may suffer similar issues as well.

@Riteo
Copy link

Riteo commented May 22, 2023

@sonic2kk

Native Wayland support may gain more interest as a result of this though, mainly for mixed-scale users where KDE's X11 scaling option doesn't help, and XWayland apps are blurry. Other DEs may suffer similar issues as well.

Note that native Wayland support doesn't automatically mean good scaling. As far as I know proper Wayland scaling implies some deeper changes in the renderer which I haven't really investigated yet.

@sonic2kk
Copy link

Indeed, usually the desktop toolkit takes care of this (GTK, Qt) and/or the underlying tech stack (Chromium for Electron apps) but in Godot's case that won't apply. I believe Wine's Wayland support is also in the same boat as requiring additional work in this regard.

Wayland support is a step in the right direction for scaling support, though, as afaik this kind of mixed-scale stuff can't really be done cleanly on the application side under X11.

@Riteo
Copy link

Riteo commented May 23, 2023

@sonic2kk

Wayland support is a step in the right direction for scaling support, though

Yup, having a Wayland backend will already improve the situation considerably for users in general.

@saolof
Copy link

saolof commented Jun 6, 2023

Possible idea for a slightly more out-there feature that I wish that at least one game engine supported: being able to have Wayland windows float inside a Godot game, essentially using Godot as a window manager.

This is primarily useful for VR productivity applications. VR headsets have the very real potential to be the form factor of the future, combining portability with theoretical maximum screen real estate. The issue has been on the software side, with all headsets so far being completely consumer focused, and my ideal would be to just have a linux distro that uses a game engine acting as the WM.

@DeedleFake
Copy link

Godot is cross-platform. If it was going to work as a Wayland compositor, I would think that it would have to have similar functionality for Windows, Mac, and others. That seems quite infeasible.

That being said, Wayland is not a particularly complicated protocol. I don't know what kind of FFI Godot has, but I suppose that it might be possible to implement some kind of plugin for Godot that uses wlroots or something to enable running a compositor in a game.

@azur-wolve

This comment was marked as off-topic.

@ffernn-dev
Copy link

ffernn-dev commented Jul 5, 2023

https://www.gamingonlinux.com/index.php?module=statistics&view=trends#SessionType-top
Looking at the statistics from this page (was linked to earlier but things have changed since), Wayland is on the way up pretty fast for gaming, and NVIDIA support is pretty good these days. I've been happily gaming and programming on Wayland for 6 months-ish now, with the only glaring issue at the moment being really awful rendering issues with apps running under Xwayland (Godot included, making it really hard to develop 😞 ).
At the risk of sounding like every linux user stereotype, I think Wayland is the way forward for linux desktops, as it's only getting better from here and I think most people would be happy to be rid of X11

EDIT: wow I didn't see how far along the PR is, that's awesome :)

@SopaDeMacaco-UmaDelicia
Copy link

SopaDeMacaco-UmaDelicia commented Oct 14, 2023

Silly question. Why not just add SDL to Godot? It can help with running on Wayland natively. Many game engines (Unreal, Unity, Source, It Tech) use it, so it's defacto a standard.

@Riteo
Copy link

Riteo commented Oct 14, 2023

@SopaDeMacaco-UmaDelicia

Silly question. Why not just add SDL to Godot? It can help with running on Wayland natively. Many game engines (Unreal, Unity, Source, It Tech, use it, so it's defacto standard.

There has been some discussion in godotengine/godot#16470 quite some time ago for SDL (platform middle layer) and a similar discussion related to bgfx (rendering middle layer) over at godotengine/godot#19602

In short, from what I can tell, it looks like it's not worth it due the fact that platform-specific workarounds will be needed anyways due to how much we integrate with each one.

AFAIK, the game engines you've listed have a way simpler integration and probably have way less resources in their platform team than us, so in that case it's not a bad idea over there, but here we already have lots of working backends and a very big API of our own.

@ssokolow
Copy link

ssokolow commented Oct 14, 2023

That's a shame. The number-one thing I value SDL for is something Godot fundamentally cannot replicate... the adoption by people like Valve as a means to inject updated platform support (Wayland, PipeWire, GNOME windeco, etc.) into statically linked games which have been abandoned by their developers via the SDL_DYNAMIC_API environment variable.

(That feature Ryan Gordon implemented where SDL's Init functions support performing runtime fixups to redirect the statically linked SDL's API surface to a newer, dynamic library copy of SDL.)

@SopaDeMacaco-UmaDelicia
Copy link

SopaDeMacaco-UmaDelicia commented Oct 14, 2023

@ssokolow Yeah, that's a really nice feature. I was able to run old game (DEFCON) on wayland natively by just using sdl12-compat layer. SDL really did a great job with the backward compatibility.

@IntangibleMatter
Copy link

Considering there's talk of xorg being deprecated in the next few years, I think that having good Wayland support is becoming more and more urgent. Especially considering how many DEs are taking a wayland-first approach now or coming up.

@RushingAlien
Copy link

Yes that is true, notable plans are

  • Fedora KDE to drop X11 session
  • GNOME to drop x11 session support
  • Budgie EFL rewrite will only have a Wayland session
  • Cosmic DE by System76 will only have Wayland session

Some stuff related to gaming

  • HDR work on Wayland is progressing

@Leshy-YA
Copy link

Leshy-YA commented Nov 21, 2023

Wayland support is becoming more important as X11 is effectively a dead project. Godot is suffering from critical issues like godotengine/godot#75308 because of this.

At this point it might be worth considering having Godot a not fully featured Wayland implementation available, so that X11 bugs, that nobody is likely to touch, don't prevent people from working and having their projects running.

@Riteo
Copy link

Riteo commented Nov 21, 2023

@Leshy-YA we already have a WIP backend over at pr godotengine/godot#57025. It's planned to be merged in 4.3, so it's only a matter of time, don't worry!

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

Successfully merging a pull request may close this issue.