-
-
Notifications
You must be signed in to change notification settings - Fork 21k
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
[WIP] Add Wayland backend to generic_unix #27463
Conversation
About client side decorations. I think that is a nice to have thing for Godot in general. I would not do it in this specific PR. But having the option to run the editor with client side decorations is a great option also for windows/macos (gives a tiny amount of additional screen space). It also does not require much. just adding a close + minimize + fullscreenbutton in the toplft/right corner and maybe optionally choose the style based on the os. |
@@ -487,8 +487,14 @@ int OS_Wayland::get_screen_dpi(int p_screen) const { | |||
return outputs[p_screen]->scale * 96; | |||
} | |||
|
|||
OS_GenericUnix *OS_Wayland::detect() { | |||
if (!getenv("WAYLAND_DISPLAY") && !getenv("WAYLAND_SOCKET")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strictly speaking, a better solution would be to actually attempt to establish a connection with the display (ditto for X11), but that would move this task much earlier in the startup process than it was before. Open to feedback on this approach.
I moved the code generation into the build system and pulled in my scons module for Wayland protocols as a git subtree: https://git.sr.ht/~sircmpwn/scons-wayland-scanner Not sure if this is entirely couth, but it fixes CI issues where checked-in generated protocol files were causing linter errors for code style. Generating Wayland protocols during the build is generally the appropriate way to do it throughout the rest of the Wayland community as well. For those unfamiliar with a git subtree, it pulls in commits from an external repository and rewrites them under a subdirectory in this repository. The files are actually checked into the repo and don't require a second step or reliable access to a second git remote to download the module on git clone. The subtree can be updated from upstream in the future with a command like |
Part two is relative pointer
Just to make testing for others quicker. |
I have issues when running:
dont have that much addional information. (fedora 29) |
what is the status on this pr? |
Been radio silence from upstream, I dunno. |
Will work on this PR still continue? |
This would likely be very difficult to rebase given the extent of the changes in the The better approach here would likely be to restart from scratch, copying code from this PR to the relevant new files ( I'd personally favor a focus on first fixing new issues that we're having with X11 since the DisplayServer split (as some might be in DisplayServer or Window code and would impact Wayland too), but re-starting the work on Wayland now would be appropriate too. |
Closing this and adding "salvageable" due to the above comment. Godot is still fairly buggy from the DisplayServer split, it might be advisable to wait a few months to work on this to avoid chasing bugs that aren't your fault. |
See godotengine/godot-proposals#990 for the new reference proposal (please help flesh it out with technical details, I just opened it as a base for further discussion about the implementation). |
Depends on #27266.
I started with @toger5's work on #23426 and cleaned things up a bit, then picked up the mantle of implementing more of the OS API for Wayland. This is still a WIP, but feedback is welcome.
Major todo items:
Future work:
Decorations is probably going to be tough, as it will require Godot to render window decorations itself. The only Wayland compositor which requires this, iiuc, is GNOME. We can probably get away with fixing it separately from the main patch.