Force Xwayland on Wayland #6
Comments
#6 When a user with QT_QPA_PLATFORM=wayland in their environment runs this application, it crashes with qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in "". It might be a good idea to set this environment variable to xcb as in https://github.com/flathub/org.keepassxc.KeePassXC/pull/71/files.
As a short term solution, we've done that. As a longer term solution, we should build the Wayland integration plugin for the included version of Qt, so that we're using Wayland whenever possible, or X11 if no Wayland is available. This seems to work OK in some brief testing on GNOME Shell 3.38.x. When we have a beta version that behaves like this, would you mind trying it in your Wayland environment? |
|
I'd be happy to! Thanks for the quick resolution :) |
Closing this issue for now, I'll open a separate one for trying to use Wayland. |
|
#15 and #16 are follow-ups from this, making the Steam Link app try to use Wayland instead of X11. Note that the "server" end of Steam Link (the fully-featured Steam client where your games are launched) still needs to be running under X11: capturing Wayland frames with Pipewire is not supported at the moment. |
|
Thanks, I was going to ask about Wayland hosts. Is there an issue I can follow for this? I'm not sure if it will affect this, but I also have Wayland issues with the Steam client around controllers, like not being able to navigate the desktop with a Steam Controller managed by Steam, and Xbox controllers not being recognized unless they are connected before Steam is launched. Are there issues I can follow for input problems like this? As more distros move to Wayland the Steam client is probably going to need to become Wayland-native since it deals with a lot of permissions-related things like desktop streaming and input management. |
Yes, but it's in the steam-for-linux "server" rather than the Steam Link client. The part that is packaged here is only the "client" end of the connection, and is entirely (or at least, mostly) Wayland-friendly, as far as I can see. ValveSoftware/steam-for-linux#6148 seems to be the issue you're looking for. The ideal Wayland-friendly approach would be for Steam to be capturing frames using Pipewire, potentially via xdg-desktop-portal, similar to Flatpak apps that implement screen-sharing. Again, this would be a feature of Steam (requested in the steam-for-linux issue tracker), and would not involve changes to this Steam Link client.
If there are, they would also be in the steam-for-linux issue tracker, not here. |
Now that we have Qt's platform plugin for Wayland, we can use that
for the shell. This is a step towards not needing X11 at all.
Test with:
Xephyr :2 &
DISPLAY=:2 flatpak run com.valvesoftware.SteamLink//master
Previously, both the shell (UI layer) and the actual streaming client
would run on the Xephyr display. After this change, the shell runs
full-screen again (via Wayland), and the actual streaming client uses
X11 by default.
The streaming client can be forced to use Wayland too by setting
environment variable SDL_VIDEODRIVER=wayland.
This reverts commit 9845f4f.
Signed-off-by: Simon McVittie <[email protected]>
When a user with
QT_QPA_PLATFORM=waylandin their environment runs this application, it crashes withqt.qpa.plugin: Could not find the Qt platform plugin "wayland" in "". It might be a good idea to set this environment variable toxcbas in https://github.com/flathub/org.keepassxc.KeePassXC/pull/71/files.The text was updated successfully, but these errors were encountered: