If you really can make this it would be awesome

Input support added, as well as a basic platform for NoGUI. Line count is up again due to being based on PR7512.

Still have to sort out the window dimensions/resizing issue, and a few other bugs.

@linkmauve would you mind giving this a test / review / help? :)

wl_shell is deprecated. Use xdg-shell instead.

Any progress?

@stenzek Any news? It would be pretty cool to have full Wayland support in Dolphin 6.0

Moved over to using xdg-shell, and the decoration manager protocol (this gets us borders/controls for NoGUI). Window size is no longer hardcoded, and resizing is supported.

The window decorations will still disappear when running with the qt frontend under gnome, but work fine on kwin. Given Qt doesn't use the wayland QPA when running under gnome anyway.. ¯_(ツ)_/¯

I'm still not sure about generating the headers and including them in the tree (approx. 2500 of the lines are from these), we might be better off generating them as part of the build process. Does anyone know what the standard practice here is?

I'm still not sure about generating the headers and including them in the tree (approx. 2500 of the lines are from these), we might be better off generating them as part of the build process. Does anyone know what the standard practice here is?

Not sure how to do this in cmake, but we use this script which is executed by our hand made configure script to do this in RetroArch.

https://github.com/libretro/RetroArch/blob/master/gfx/common/wayland/generate_wayland_protos.sh

It will require wayland-scanner and wayland-protocols to accomplish, the latter can be added to external. We fallback to our own copy if the user's version is not installed.

Yeah, I was considering using cmake to shell out to wayland-scanner.. getting the location on system without hardcoding it to /usr/share or whatever could be interesting.

I was worried about that too so I made it check $SHARE_DIR/wayland-protocols, /usr/local/share/wayland-protocols and /usr/share/wayland-protocols in that order where $SHARE_DIR is the output of --datarootdir. I am not sure that is perfect, but so far I haven't seen anyone complain about it not working. However it will fallback to our deps/wayland-protocols if either none of them are found or our earlier check for version >= 1.15 of wayland-protocols.pc fails (Using pkg-config/pkgconf). I've been told that earlier versions are not good enough and not all distros carry recent versions...

@linkmauve thanks for the tip, I did come across the ECM modules but wasn't sure how widespread the support was. Sounds like the most straightforward method.

Here's what I've come up with so far. It uses subsurfaces and runs but

• Size is hard coded to 640x480. Need to get the inner dimensions of the render window somehow and the size when it goes fullscreen.
• Likewise, the offsets passed to wl_subsurface_set_position() are hard coded, so the emulation window isn't perfectly affixed to the render window providing the decorations.
• Moving the pointer over the emulation window causes a crash with the message QObject::connect(QtWaylandClient::QWaylandWindow, QtWaylandClient::QWaylandInputDevice::Pointer): invalid null parameter and I don't know why.
• Vulkan currently does not work, only GL does.

There's also the matter of hooking up keybindings etc. but since it runs, I'd say it's about half way there. Any help solving these problems is welcome.

I decided against using subsurfaces for this case, because to me it seems like it creates a bunch of problems, e.g. what size are the decorations? are the decorations round or square? I also wanted to avoid having a large chunk of wayland code in the qt frontend. It's also the only system where this is even a question, no other OS/display manager has this problem.

I'm guessing Qt creates subsurfaces itself for the render-to-main-window case, because this works fine in my branch when taking over the surface for Dolphin's rendering. The separate window works as expected with server-side decorations.

Size is hard coded to 640x480. Need to get the inner dimensions of the render window somehow and the size when it goes fullscreen.

Implemented in this PR. The size is passed as part of the WSI info at startup, with resize events being passed to the backend, updating the surface as needed. See e81c726 and 6c8aec0

Vulkan currently does not work, only GL does.

Also implemented in this PR.

Great. You might check the cmake code I have, it might give you some ideas.

@stenzek I tested your code, it built fine and works (mostly). Mousing over and Vulkan with Qt is good but trying nogui ended up with xwayland. The keyboard did not work except in fullscreen, Esc caused crash and Alt+Enter got out of fullscreen but restarted emulation and left the main gui unresponsive (had to ctrl+c to stop emulation and exit). The keyboard should be hooked up for save/load state, Esc to quit properly and toggle fullscreen etc. Click to move emulation window would be nice to have too. It's a shame to see subsurfaces are more or less a waste of time but at least SSD is (apparently) an option now.

Great. You might check the cmake code I have, it might give you some ideas.

I've been planning to move it over to the ECM module, just haven't had time yet.

Mousing over and Vulkan with Qt is good but trying nogui ended up with xwayland.

dolphin-emu-nogui -p wayland .... It'll default to X11 otherwise.

Now using ECM's scripts for wayland, as suggested by @linkmauve. I think this can be considered complete now, since CSD is outside the scope.

It pulls in xkbcommon without hooking up the keyboard. Keyboard bindings need to be hooked up still. I'm not entirely sure but judging from latest simple-egl.c in weston, xkbcommon isn't needed to get key events.

Another problem I have found is that after building (with wayland enabled), fullscreen no longer works in x11. With wayland disabled, emulation video is broken with x11. The window doesn't come up when audio starts and if it does show up, it only displays a single frame and never updates. So this PR breaks 'normal' x11 functionality quite badly.

EDIT: With latest changes it's even worse. I get audio and a window, but the window receives no frames so it ends up showing garbage (remnants of the desktop). I also tried disabling EGL but it makes no real difference.

It is hooked up to the keyboard. See 6d51b71. Did you change the input device in the controller options? Wayland will show up as a different device to xinput.

I'll look into the X11 issues.

Now that I changed the keyboard in hotkey config, the keybindings work. One other bug I noticed though, when I press Super key (while running under wayland) while in main dolphin window when emulation is not running, dolphin segfaults (regardless what 'keyboard' I select). I built with debug symbols to get this back trace http://ix.io/1HSQ

@soreau I'm unable to reproduce any of the X11 issues you've mentioned, regardless of egl/wayland/etc config options.

@stenzek After trying various things I did manage to get it 'working' by disabling compositing window manager but it's extra slow (tww) and dolphin 5c5e6df works fine with compositing at expected speeds. With your code, while the compositing wm is running and the emulation window displaying garbage, the audio is still slowed. Are you using a compositing window manager? I am surprised you can't reproduce because the problem is obvious on my end.

I tried both kwin and mutter? (or whatever the gnome compositor is) on Ubuntu 19.04.

edit: fwiw, I looked through the changes again, and I can't really how anything would affect X11 using GLX compared to master.

Whether ENABLE_WAYLAND is set or not should definitely not change anything for X11.

Worth noting that the earliest ubuntu that will support this without PPAs is 19.04. This shouldn't be a problem once CMake can just flip it on/off at configure time but for people not on rolling release distros, it may be worth sticking a small note in the README for ubuntu users hoping to leverage wayland support.

@stenzek You sure you weren't using kwin and mutter wayland compositors? I'll try to bisect on my end if I can find a good commit.

Oh hi Stenzek, good to see you back on this PR! Are there any tweaks left we could help with?

I got a crash when pressing ctrl+q to quit. Unfortunately the trace is not very helpful since I didn't have libwayland debug symbols. I will try to reproduce.

https://0x0.st/-AlV.txt

I notice this when building:

[ 80%] Generating wayland-xdg-shell-protocol.c
[ 80%] Generating wayland-xdg-decoration-protocol.c
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
Using "code" is deprecated - use private-code or public-code.
See the help page for details.

Reference

I got a crash when pressing ctrl+q to quit. Unfortunately the trace is not very helpful since I didn't have libwayland debug symbols. I will try to reproduce.

https://0x0.st/-AlV.txt

Here's what I get with Ctrl+Q. I didn't see this in the Dolphin keybinding settings which makes me wonder if Qt is listening and taking action, and Dolphin isn't expecting it.

Also in my case, even if all the required wayland development packages are installed, wayland is still not automatically enabled. I had to manually enable wayland with -DENABLE_WAYLAND=1 or else there is this message when attempting to start emulation:

ctrl+q is a shortcut to send sigterm to the focused window on my compositor, and a general shortcut on many qt/qtk programs. If dolphin itself doesn't implement it as a shortcut it should still handle it properly.

I think it makes sense to enable Wayland by default until there's a good reason not to.

Just voicing my interest in this PR as a fellow Wayland (sway) user.

+1 any progress on this?

If anybody wants to build or run this PR using nix, they can do so like this:

Build (Puts it in ./result/bin/dolphin-emu)

nix build github:matthewcroughan/nixpkgs/dolphin-wayland-hack#dolphinEmuMaster

Run (Just runs dolphin-emu)

nix shell github:matthewcroughan/nixpkgs/dolphin-wayland-hack#dolphinEmuMaster --command dolphin-emu

I created a .patch that is based on this pr's work and rebased on 6e7698a. Here's the patch:
https://pastebin.com/yChuyxcu.

My efforts were like a monkey smashing a keyboard. I just fixed some function signatures and it seems to compile on gcc11. I'm not sure how stable it is, but it seems to launch opengl/vulkan on wayland now on a couple of games I tried. This is running archlinux and sway (HiDPI seems to work as well)
I did make one change from the original patch, and that is to have cmake enable wayland by default. Before you had to set the ENABLE_WAYLAND option. I just decided to do that because people using this .patch would probably already want to be doing that.

@Need4Speed402 Thank you so much. I have made a commit here MatthewCroughan/nixpkgs@3863ef1 that will allow anyone viewing this PR to use Nix on any distribution (including Arch 😄) to test your patch. I've tested it as working under Sway on NixOS too.

Build Need4Speed402's patch (Puts it in ./result/bin/dolphin-emu)

nix build github:matthewcroughan/nixpkgs/dolphin-wayland-hack-n4s#dolphinEmuMaster

Run Need4Speed402's patch (Just runs dolphin-emu after building it)

nix shell github:matthewcroughan/nixpkgs/dolphin-wayland-hack-n4s#dolphinEmuMaster --command dolphin-emu

Any indication on why this was closed?
Is the patch nonviable or does it just need someone to clean it up before it can be pulled?

Feel free to rebase this as a new PR if you're willing to get this into a mergeable state.

Feel free to rebase this as a new PR if you're willing to get this into a mergeable state.

It would be nice to know from upstream maintainers if this work would even be accepted if such a PR exists, before doing the work.

Any indication on why this was closed?

Stenzek closed all his open PRs. So it's not because something was wrong with this PR specifically.

I did rebase this PR recently here and it seems to apply cleanly on current dolphin still. I have played some games through it and I can say that the only issue is really just the mouse cursor not hiding itself when it should be. I know there was some chit chat about the PR not rendering window decorations on Gnome? Maybe somebody should test that. I would be willing to clean this up and put up a new PR but life's kinda busy right now so I'd rather not.

Any news here?

I rebased the patches again on commit 3da6487. Works fine on sway git.

I rebased the patches again on commit 3da6487. Works fine on sway git.

Thanks.
So what step should be done afterwards?

What's holding this back from being merged currently?

What's holding this back from being merged currently?

The fact that this PR is closed.