application failed to start because no Qt platform plugin could be initialized

[Duxon]

trafficstars

Since I have updated to 1.1.82.200, the application no longer launches. Instead, it closes with the following error:

(base) duxon@penguin:~$ flatpak run com.valvesoftware.SteamLink 
qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

This happens on a Debian (buster) on Crostini where I had no issues before. Any ideas why that happens?

[smcv]

This is probably a regression caused by #16.

Do you have an environment variable like QT_QPA_PLATFORM set, forcing Qt to use its xcb plugin?

Please try each of these possible workarounds:

• flatpak run --unset-env=QT_QPA_PLATFORM com.valvesoftware.SteamLink
• flatpak run --socket=x11 --nosocket=fallback-x11 com.valvesoftware.SteamLink

If the first one works, we can put the equivalent of that in the metadata and it should solve this.

If the first one doesn't work, the second one basically reverts #16, which weakens the sandboxing (and will display scary warnings in GNOME Software) but should make the app work again.

[smcv]

It would also be interesting to know whether you have the same problem with other Qt Flatpak apps that use fallback-x11, like https://github.com/flathub/org.kde.kid3, https://github.com/flathub/org.kde.kontrast or https://github.com/flathub/org.qelectrotech.QElectroTech.

[Duxon]

Thanks for your quick reply! The workarounds didn't work for me:

• flatpak run --socket=x11 --nosocket=fallback-x11 com.valvesoftware.SteamLink as well as running org.kde.kontrast lead to the same error as before.

• The environment variable QT_QPA_PLATFORM was not set. After setting it with export QT_QPA_PLATFORM=xcb, running flatpak run --unset-env=QT_QPA_PLATFORM com.valvesoftware.SteamLink closes with error: Unknown option --unset-env=QT_QPA_PLATFORM

I'm starting to believe that Crostini (the Linux sandbox under Chrome OS) might be the root of the issue.

[smcv]

flatpak run --socket=x11 --nosocket=fallback-x11 com.valvesoftware.SteamLink

Sorry, the socket arguments get a bit confusing around fallback-x11. Perhaps try: flatpak run --nosocket=wayland com.valvesoftware.SteamLink

I'm starting to believe that Crostini (the Linux sandbox under Chrome OS) might be the root of the issue.

Outside the sandbox, what are $XDG_RUNTIME_DIR, $DISPLAY and $WAYLAND_DISPLAY?

Outside the sandbox, where is your X11 socket?

Outside the sandbox, where is your Wayland socket?

Does running flatpak run -vv ... shed any more light on the situation?

error: Unknown option --unset-env=QT_QPA_PLATFORM

Which version of Flatpak is this?

In older versions you'd have to use --env=QT_QPA_PLATFORM= instead of that - but if QT_QPA_PLATFORM wasn't set anyway, then that can't be the problem.

[Duxon]

Perhaps try: flatpak run --nosocket=wayland com.valvesoftware.SteamLink

That works!

Outside the sandbox, what are $XDG_RUNTIME_DIR, $DISPLAY and $WAYLAND_DISPLAY?

echo $XDG_RUNTIME_DIR $DISPLAY $WAYLAND_DISPLAY returns /run/user/1000 :0 wayland-0.

Outside the sandbox, where is your X11 socket/where is your Wayland socket?

I have no idea how to figure that out, sorry.

Which version of Flatpak is this?

Flatpak 1.2.5

[smcv]

Does running flatpak run -vv ... shed any more light on the situation?

You didn't answer this. What messages do you get when you run in the mode that is not working (without using the --nosocket=wayland workaround), but with -vv to make Flatpak more verbose?

Outside the sandbox, where is your X11 socket/where is your Wayland socket?

I have no idea how to figure that out, sorry.

With the additional information you already provided, I can be more specific. Does /run/user/1000/wayland-0 exist and is it owned by your uid 1000?

It should look something like this:

$ ls -l /run/user/1000/wayland-0
srwxr-xr-x 1 smcv smcv 0 Nov 16 16:41 /run/user/1000/wayland-0

Flatpak 1.2.5

That's a few years old. Would you be able to try Flatpak 1.10.x from buster-backports, or alternatively, upgrading from Debian 10 'buster' to Debian 11 'bullseye'?

[Yariazen]

I have I believe the same issue in flatpak 1.10.5 also on crostini. Wayland-0 is owned by uid 1000, and here's the verbose: https://paste-bin.xyz/18016 Don't know if it helps but I solved it for myself by installing flatseal and disabling fallback to x11 windowing system

[Duxon]

I have I believe the same issue in flatpak 1.10.5 also on crostini. Wayland-0 is owned by uid 1000, and here's the verbose: https://paste-bin.xyz/18016

Yes, the verbose output is the exactly same for me. Unfortunately, installing Flatpak 1.10.x from buster-backports does not work using this guide (due to broken dependencies). Upgrading the crostini container to buster could be possible, but could also break Crostini which I can't afford to test right now. I am glad there is a nosocket=wayland workaround. That wasn't necessary about 1.5 months ago, however.

[smcv]

The problem here appears to be:

• the Flatpak app manifest is configured to give the app access to Wayland if available, or X11 if Wayland is not available
• the Wayland socket is available
• so the Wayland socket is shared with the app, and the X11 socket is not
• but for some reason Wayland doesn't work in this Crostini environment (at least for this particular app)
• so the app fails

[smcv]

Unfortunately, installing Flatpak 1.10.x from buster-backports does not work using this guide (due to broken dependencies)

What you need is the same instructions that are described there for bullseye-backports, except replace every occurrence of bullseye-backports with buster-backports because you are still running on buster. Does that work? If not, please report it to Debian as a bug in the flatpak package (I am also the maintainer of that package), because installing buster-backports packages on buster should succeed.

[smcv]

Running this app with flatpak run --socket=wayland --env=QT_DEBUG_PLUGINS=1 com.valvesoftware.SteamLink might help to figure out why it isn't using the Wayland socket?

[Duxon]

Using buster-backports instead of bullseye-backports works. I am now running Flatpak 1.10.5.

However, the verbose error stays the same as before. Running Steam Link with --socket=wayland --env=QT_DEBUG_PLUGINS=1 yields this: https://paste-bin.xyz/18071