replace x11 socket with fallback-x11

[sonic2kk]

Resolves DavidoTek/ProtonUp-Qt#284.

Flathub now lists security/permission related information about Flatpaks. ProtonUp-Qt is flagged as "potentially unsafe" and one of the reasons for this is "using a legacy windowing system". This is caused by ProtonUp-Qt enabling the x11 socket by default, instead of using fallback-x11.

ProtonUp-Qt has a lot of things flagging it at time of writing, most of which we can't do much about: accessing specific files for installing compatibility tools to specific folders, "acquire arbitrary permissions" which is caused by some specific file permissions, and accessing devices for gamepad support. This legacy windowing system warning, however, is something we can hopefully resolve, provided issues related to Qt are fixed.

Previously, this had some issues due to a regression with Qt6, and was removed (0a4fd4e). We can use this PR to test. I tested myself with fallback-x11 enabled and x11 disabled using Flatseal to do so, and tested the native Wayland support and forcing X11 support with QT_QPA_PLATFORM="xcb". Everything appeared to work fine in testing. I had this enabled for a while and actually completely forgot again, and it has worked with my general usage of ProtonUp-Qt that I didn't even realise this option was enabled. I confirmed when X11 was in use with xeyes and also I could tell because Xwayland applications are blurry on my scaled display, whereas Wayland applications are crisp.

Testing was conducted with ProtonUp-Qt Flatpak from Flathub, and primarily tested with the PySide6 6.5.2 bump, which fixed a all of window artifacting problems on scaled displays, so I would hope that if any issues were still present with older PySide6 versions, that they would now be fixed.

[flathubbot]

Started test build 67276

[flathubbot]

Build 67276 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/49937/net.davidotek.pupgui2.flatpakref

[DavidoTek]

Thanks for doing the testing.

Previously, this had some issues due to a regression with Qt6, and was removed (0a4fd4e).

I think the issue in DavidoTek/ProtonUp-Qt#77 was that older version of GNOME/Qt tried to use X11/XWayland even when Wayland was available.

tested the native Wayland support and forcing X11 support with QT_QPA_PLATFORM="xcb".

In a GNOME 44.4 Wayland session, when running QT_QPA_PLATFORM=xcb flatpak run net.davidotek.pupgui2, I get the same issue as in # 77:

ProtonUp-Qt 2.8.2 by DavidoTek. Build Info: DavidoTek Flathub build.
Python 3.10.13 (main, Nov 10 2011, 15:00:00) [GCC 12.2.0], PySide 6.5.2
Platform: KDE Flatpak runtime 6.5 Linux-6.4.15-200.fc38.x86_64-x86_64-with-glibc2.35
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, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-egl, wayland, xcb.

/app/bin/net.davidotek.pupgui2: Zeile 3:     3 Abgebrochen             (Speicherabzug geschrieben) python3 -m pupgui2 "$@"

So with fallback-x11, running Wayland on Wayland and running X11 on X11 works fine, but running X11 on Wayland does not. I wonder if there is still a scenario like the above mentioned where Qt would try to use X11 even when Wayland is available.

Which desktop environment did you use?

[sonic2kk]

I spent a lot of time testing to try and figure out what happened, but it turns out you're correct, forcing X11 seems to cause the error you're showing of no backend being available. Sorry for the confusion! For what it's worth, I'm using KDE Plasma Wayland 5.27.8.

I did a quick look around and I wonder if perhaps this is expected behaviour? The error is caused by a missing library, likely in this case a missing X11 library, and this may be intentional in the Flatpak. This is only a guess, but fallback-x11 may not simply mean using X11 if it is forced, but only falling back to X11 if a Wayland backend is unavailable, i.e. if Wayland is not accessible at all. If there was a way to perhaps spoof to Flatpak that we're running under X11, maybe it would then try to load X11.

I wonder what this would mean for toolkits with no Wayland support (such as old GTK2 applications, or Tkinter). I have no idea how Flatpak would be able to "cut off" X11 support. But maybe we're on the wrong track with this being a regression?

I found this post on the Qt forums from 2020 which seems to back up the idea that this is related to a missing library -- Of course in that post it was entirely unrelated to Flatpak, but it does back up the idea in my mind that Flatpak is preventing proper access to X11/Xwayland.

In another, unrelated project, I found this discussion post. In it, the error message was slightly different: Could not load the Qt platform plugin "xcb" in "/(...)site-packages/cv2/qt/plugins" even though it was found. -- Note the path in the brackets, it appears that it's trying to find the xcb Qt plugin. Since the path in our Flatpak error message is blank, it may very well be that it's blocking off paths to X11 backends.

Finally, I tried running ProtonUp-Qt Flatpak with the following two environment variables:

QT_QPA_PLATFORM=xcb QT_DEBUG_PLUGINS=1 net.davidotek.pupgui2`

And the results were interesting. Mainly, the last few lines:

qt.core.plugin.factoryloader: Got keys from plugin meta data QList("offscreen")
qt.core.plugin.factoryloader: checking directory path "/usr/bin/platforms" ...
qt.core.library: "/app/lib/python3.10/site-packages/PySide6/Qt/plugins/platforms/libqxcb.so" loaded library
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.

I'm not well-versed in the lower level end of display managers to really comment on what's going on, but it really sounds like to me from all of this that Flatpak is explicitly blocking X11 backends on Wayland.

---

If this really is what Flatpak is doing, the question becomes, how safe is this? As you mentioned:

I wonder if there is still a scenario like the above mentioned where Qt would try to use X11 even when Wayland is available.

I am not sure how likely such a scenario is, and I'm not confident enough to say that it's even unlikely, because truthfully I don't know. I use KDE and use Qt applications on a daily basis, and I haven't come across a case like this, and since we're running in a Flatpak container we should be able to assume that the runtime will function the same across distributions.

The failure to load the X11 release on Wayland could be intentional.

---

I suppose the real thing that would help put this to bed, is to test other Qt Flatpaks with this option, and see if they fall over...

[DavidoTek]

but it really sounds like to me from all of this that Flatpak is explicitly blocking X11 backends on Wayland

I think that is the case.

The Flatpak Permissions Reference Page states following: --socket=fallback-x11 Grant X11 access when Wayland is not available

I have no idea how Flatpak would be able to "cut off" X11 support

Flatpak uses a sandbox. Something like Firejail. I'm not sure what sandbox they are using in the background or if they have their own implementation. It is possible to block access to unix sockets (what x11 is using) and to the file system. That is also why xdg portals exist for example.

qt.core.library: "/app/lib/python3.10/site-packages/PySide6/Qt/plugins/platforms/libqxcb.so" loaded library
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.

It kinda sounds like it is successfully loading the shared library but it will fail to execute without x11 and thus cannot be loaded.

I use KDE and use Qt applications on a daily basis, and I haven't come across a case like this, and since we're running in a Flatpak container we should be able to assume that the runtime will function the same across distributions.
I suppose the real thing that would help put this to bed, is to test other Qt Flatpaks with this option, and see if they fall over...

Yeah, I guess we could check how other applications solve the issue. Older version of Qt defaulted to using X11 with GNOME even when Wayland was available, this is what caused the issue. It was however possible to force Qt to use Wayland anyway when it is available. Newer versions of Qt should not have this problem.

If there was a way to perhaps spoof to Flatpak that we're running under X11, maybe it would then try to load X11.

If there was a way to do this from inside the Flatpak, it would definitvly be a security vunerability in the sandbox. Spoofing from the "outside" should be possible, but that isn't applicable here.

---

What we should probably do first is to check what other apps are doing about it.

If there isn't any completely different solution out there to what we discussed above, we should then check if there is any case where Qt would use X11 even if Wayland is available. If there is no such case, we can replace x11 by fallback-x11 without worrying.

In case there is any relevant case where Qt uses X11 over Wayland, we should delay the merger of this PR. By relevant I mean on a system that gamers are likely to use. Not some edge-case like Ubuntu 14.04 running Unity. They can still revert to using the AppImage.

---

What we should probably do first is to check what other apps are doing about it.

There seem to be quite a few apps using fallback-x11 and Qt 6: https://github.com/search?q=org%3Aflathub+fallback-x11+kde&type=code

Others were doing the same: flathub/org.plomgrading.PlomClient#94

we should then check if there is any case where Qt would use X11 even if Wayland is available

Haven't found anything with a quick google search....