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

[WIP] Add Wayland backend to generic_unix #27463

Closed
wants to merge 52 commits into from
Closed

[WIP] Add Wayland backend to generic_unix #27463

wants to merge 52 commits into from

Conversation

ddevault
Copy link

@ddevault ddevault commented Mar 27, 2019

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:

  • Improved HiDPI support
  • Video driver selection
  • Update build system
  • Choose the most suitable backend on startup in main.cpp
  • Compile Wayland protocols with scons
  • Re-evaluate EGL context creation
  • Default Godot cursor images
  • Mouse visible/hidden
  • Pointer constraints (for locking the mouse to the window)
  • Clipboard support
  • Keep screen on (idle inhibit)

Future work:

  • xdg-decoration support (borderless & bordered windows)
  • Adjust editor DPI auto-selection as the window moves between outputs of various DPIs
  • Key repeat
  • Pointer frames
  • Virtual keyboard (OSK) rigging
  • Custom cursor images

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.

@toger5
Copy link
Contributor

toger5 commented Mar 28, 2019

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.

@Chaosus Chaosus added this to the 4.0 milestone Mar 30, 2019
@@ -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")) {
Copy link
Author

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.

@ddevault
Copy link
Author

ddevault commented Apr 1, 2019

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 git subtree pull -P platform/generic_unix/tools/wayland-scanner https://git.sr.ht/~sircmpwn/scons-wayland-scanner master.

@toger5
Copy link
Contributor

toger5 commented Apr 11, 2019

Just to make testing for others quicker.
These additional libs are needed on fedora:
mesa-libEGL-devel
egl-wayland-devel
libxkbcommon-devel
wayland-devel

@toger5
Copy link
Contributor

toger5 commented Apr 11, 2019

I have issues when running:

wl_registry@2: error 0: invalid version for global wl_output (4): have 2, wanted 3
WARNING: _get: Property not found: rendering/quality/driver/driver_fallback
   At: core/project_settings.cpp:193.
ERROR: is_viable: Error initializing GLAD
   At: drivers/gles3/rasterizer_gles3.cpp:142.
WARNING: _get: Property not found: rendering/quality/driver/driver_fallback
   At: core/project_settings.cpp:193.
**ERROR** OS_Unix::execute - Could not create child process while executing: xmessage

dont have that much addional information. (fedora 29)

@akien-mga akien-mga requested review from hpvb and removed request for karroffel and neikeq May 28, 2019 10:46
@toger5
Copy link
Contributor

toger5 commented Jun 16, 2019

what is the status on this pr?

@ddevault
Copy link
Author

Been radio silence from upstream, I dunno.

@aaronfranke aaronfranke mentioned this pull request Nov 5, 2019
@aaronfranke aaronfranke marked this pull request as draft April 9, 2020 00:36
@qarmin
Copy link
Contributor

qarmin commented Apr 20, 2020

Will work on this PR still continue?
If not, would it be possible to rebase pr with already implemented functions to the master branch?
In the meantime a significant part of the code was moved to displayerver class and x11 was changed to linuxbsd (of course where it did not refer to xorg).

@akien-mga
Copy link
Member

This would likely be very difficult to rebase given the extent of the changes in the master branch for the OS / DisplayServer split. (Which is also why this and other related PRs have not been reviewed for merging, as they were all pending on this DisplayServer split to happen for 4.0.)

The better approach here would likely be to restart from scratch, copying code from this PR to the relevant new files (platform/linuxbsd/display_server_wayland.cpp, etc.).

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.

@aaronfranke
Copy link
Member

aaronfranke commented May 26, 2020

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.

@akien-mga
Copy link
Member

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

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

Successfully merging this pull request may close these issues.

7 participants