Crashing on ChromeOS due to Wayland

[tuqqo]

Describe the bug
App is crashing when selecting something in any dropdown menu.

To Reproduce
Start App, select any Engine (steam for example), click Add Version, select something in the dropdown
-> Crash

Expected behavior
No crash

Desktop (please complete the following information):

• Platform: Chromebook
• System: ChromeOS 119
• Version: ProtonUp-Qt 2.8.2
• How did you install ProtonUp-Qt?: Flatpak

Terminal output

qt.pysideplugin: Environment variable PYSIDE_DESIGNER_PLUGINS is not set, bailing out.
qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found.
Gamepad error: No gamepad found.
qt.qpa.wayland: Ignoring unexpected wl_surface.enter received for output with id: 7 screen name: "Screen5" screen model: "unknown" This is most likely a bug in the compositor.
qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found.
qt.qpa.wayland: Ignoring unexpected wl_surface.enter received for output with id: 7 screen name: "Screen5" screen model: "unknown" This is most likely a bug in the compositor.
qt.qpa.wayland: Ignoring unexpected wl_surface.enter received for output with id: 7 screen name: "Screen5" screen model: "unknown" This is most likely a bug in the compositor.
The Wayland connection broke. Did the Wayland compositor die?

Propably a QT Problem ?!
eliranwong/UniqueBible#68
https://bugs.launchpad.net/bugs/2043867

[sonic2kk]

Likely related to Qt, ProtonUp-Qt uses PySide6 and doesn't talk to anything as low level as Wayland directly (that's all handled by Qt). Also, I'm not sure if ProtonUp-Qt "officially" targets ChromeOS, so that could be an issue.

I'm not sure that this issue is specific to ProtonUp-Qt or something it can fix, it may be fixed by a PySide / KDE Runtime version bump, but that's really an upstream issue.

---

As a workaround, you can disable the Wayland socket in a tool such as Flatseal (also available as a Flatpak), if ChromeOS doesn't offer a built-in way of editing Flatpak settings. This will force ProtonUp-Qt (or any Flatpak that you use this setting for) to run on X11.

[tuqqo]

Yea i kinda thought the same. It's not the first ChromeOS upstream problem that magically fixes itself after some random update 🤷🏻‍♂️ thanks for the workaround tho!! Gonna try later 👍

[sonic2kk]

No problem, using Xwayland isn't always seamless but that is, once again, an upstream issue (likely Xwayland would be the place to report that, since it manages how X11 apps run on Wayland).

I should also note that this is assuming your ChromeOS installation has XWayland (it's a common dependency if nothing else), and also that this Wayland crash is likely exclusive to ChroneOS. I'm running ProtonUp-Qt on Plasma Wayland and have been for a long time, and while there are still some visual bugs, there aren't any crashes.

@DavidoTek We should keep this in mind before merging flathub/net.davidotek.pupgui2#24, I'm not sure that the fallback handles crashes like this, my guess is that it would not. Then again, because this is upstream, it may not be something ProtonUp-Qt has to be concerned about.

[DavidoTek]

@DavidoTek We should keep this in mind before merging flathub/net.davidotek.pupgui2#24, I'm not sure that the fallback handles crashes like this, my guess is that it would not

Yeah, that is the reason why I'm still stalling. Let's wait for @tuqqo 's response what happens when disabling Wayland.

As a workaround, you can disable the Wayland socket in a tool such as Flatseal

Also @tuggo, can you try to disable x11 and instead enable both wayland and fallback-x11 and see what happens?

I'm not sure if ProtonUp-Qt "officially" targets ChromeOS

I haven't actively added features for it, but as long it doesn't break anything else, I guess we can at least maintain it in a working state. If there is anything else to consider/improve, I'm open for it.
I wonder, does ChromeOS support Wayland at all, and is the Linux support still actively supported? Afaik it is some sort of Ubuntu running in a Docker/chroot, right?

[sonic2kk]

I was unsure if ChromeOS supported Wayland, I just took OPs word for it, though it surprised me I also could see that being the case depending on how the Linux support is setup.

I think the Linux side is still supported, as I still see people on ChromeOS trying to run games via Proton on the Proton issue tracker, making reference to the Mesa drivers as well. I'm not too sure how it's set up, but the way you've described it does sound about right.

It seems like Wayland was actually used for Android and Linux apps, but actually, it looks like ChromeOS may soon use Wayland by default everywhere.

Previously ChromeOS was using a homemade graphics stack called "Freon," but now with Wayland, it'll be on the new and normal desktop Linux graphics stack. [...] Google says this represents "more Wayland support" because Wayland was previously used for Android and Linux apps, but now it'll be used for the native Chrome OS graphics, too.

I don't own a Chomebook to verify but it seems like Linux applications do use Wayland on ChromeOS. That doesn't mean they have support for Xwayland though, and however their Wayland support is implemented may either be buggy, or may be exposing upstream bugs. So I do wonder if disabling the Wayland socket will work after all, if there is no X11/Xwayland :-)

One Reddit comment suggests only Wayland is available and not X11, but it was from two years ago. OP linked an issue to a bug on ChromeOS for another application, UniqueBible, where the developer noted two years ago that there may be a bug in the Wayland compositor used in ChromeOS. I believe this application also uses Qt, either with PySide6 if available, and falling back to pyqt otherwise (repo search link). In their commit that supposedly fixes the Wayland compositor crash, I cannot discern what exactly fixes it, and while it may also be a Qt/PySide6 bug with Wayland on ChromeOS, it may be a separate bug to what is happening here.

Based on OPs terminal output though ("The Wayland connection broke. Did the Wayland compositor die?"), I think this is probably an upstream issue, either with PySide6/Qt6, or the Wayland compositor used on ChromeOS. But if it there is something other Qt apps are doing to fix this issue on ChromeOS there's no reason ProtonUp-Qt couldn't adopt it, if it's relatively straightforward to implement.

[tuqqo]

Hey, sorry I'm not able to test until tomorrow at my Chromebook. But yes, the debian container on ChromeOS (crostini) is powered by Wayland. But it's not yet finished as mesa drivers are still an issue cause of Vulkan API. Once finished it will be full Vulkan API on Wayland. It's not yet officially implented. And yes, until then there are always a couple of upstream problems like this, when one thing depends on something else. I saw a couple in my 2 years using ChromeOS and all of them got fixed in the regular debian/crostini package updates after some time. I guess a container in a container is more prone to errors. It's a little like some flatpak apps sometimes have odd anomalies. Basically 95% of the Linux container runs perfectly. And no it's not docker afaik, they are past that already. But the whole ChromeOS is based on containers. Main ChromeOS (crouton, based on gentoo) with it's debian Linux Subsystem (crostini) and the arcvm android container.

[tuqqo]

ok, im done testing.

x11 on + wayland off + xwayland fallback off = working
x11 off + wayland on + xwayland fallback on = crash
x11 off + wayland off + xwayland fallback on = working
x11 off + wayland on + xwayland fallback off = crash
x11 on + wayland on + xwayland fallback on = crash
x11 off + wayland off + xwayland fallback off = not starting

[tuqqo]

uname -a
Linux penguin 6.1.55-06876-gecce3ad0352d #1 SMP PREEMPT_DYNAMIC Sat Nov 11 18:44:44 PST 2023 x86_64 GNU/Linux

cat /proc/version
Linux version 6.1.55-06876-gecce3ad0352d (chrome-bot@chromeos-release-builder-us-central1-b-x32-23-y0bg) (Chromium OS 17.0_pre498229-r6 clang version 17.0.0 (/mnt/host/source/src/third_party/llvm-project 14f0776540b5a49e1c42f49a01213f7f3fa047bf), LLD 17.0.0) #1 SMP PREEMPT_DYNAMIC Sat Nov 11 18:44:44 PST 2023

env | grep -E -i 'x11|xorg|wayland'
WAYLAND_DISPLAY_LOW_DENSITY=wayland-1
WAYLAND_DISPLAY=wayland-0

glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa/X.org (0x1af4)
Device: virgl (Mesa Intel(R) UHD Graphics (JSL)) (0x1010)
Version: 21.2.6
Accelerated: yes
Video memory: 0MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.3
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: virgl (Mesa Intel(R) UHD Graphics (JSL))
OpenGL core profile version string: 4.3 (Core Profile) Mesa 21.2.6
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.1 Mesa 21.2.6
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.2.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

[DavidoTek]

It seems like Wayland was actually used for Android and Linux apps, but actually, it looks like ChromeOS may soon use Wayland by default everywhere.
the debian container on ChromeOS (crostini) is powered by Wayland

That's good I guess.

I believe this application also uses Qt, either with PySide6 if available, and falling back to pyqt otherwise (repo search link)
In their commit that supposedly fixes the Wayland compositor crash, I cannot discern what exactly fixes it

Hmm interesting. We should keep that in mind then.
I don't feel like implementing two different Main Windows is a good idea. We should look into what is actually making the difference and see if it possible to implement than in a util function or something.

Main ChromeOS (crouton, based on gentoo) with it's debian Linux Subsystem (crostini) and the arcvm android container.

Ah okay.

x11 on + wayland off + xwayland fallback off = working
x11 off + wayland off + xwayland fallback on = working

Seems like it is only working when Wayland is disabled and it is using X11.

[sonic2kk]

Yeah, I definitely don't think two main windows is a maintainable solution either.

It's good to know that it works without X11 and that for now this is a viable workaround on ChromeOS. I don't think we can really handle telling Qt which to pick unfortunately. Since ChromeOS runs things in containers, setting an environment variable really early on if we "detect" ChromeOS would be very flimsy as well.

We'd have to find out what's causing this issue on ChromeOS, and beyond that, we'd also be best removing it once this is fixed. I'm not sure if it's Qt or ChromeOS' Wayland compositor causing the crash - it could just be a poorly implemented compositor, or Qt could be making some incorrect assumptions about whet the compositor implements. It's not uncommon for applications to require a certain Wayland version either which ChromeOS may not meet. For example, GameScope requires Wayland Server >= 1.21, and Wayland Protocols >= v1.17. I couldn't find if Qt6.5 which I believe our PySide6 version uses, has any such minimum Wayland version requirements. Likewise, I'm not sure what version of Wayland that ChromeOS' container(s?) ship with.

I bring this up as the graphics drivers listed here, Mesa 21.2.6, are about two years out of date. It's not impossible that, if based on something like Debian, the container just has very old libraries. I'm not sure how much of this part (managing Wayland protol versions etc) is handled by the Flatpak KDE Runtime.

There could be a number of issues here, and what I wanted to highlight here is that some of it may be out of an application maintainer's hands to fix, and also that even if we can fix it, the "real" fix will hopefully, eventually, come from upstream, so ideally ChromeOS won't become a maintenance burden and either ChromeOS or Qt will support Wayland on the desktop in such a way that this is properly abstracted away.

[tuqqo]

There could be a number of issues here, and what I wanted to highlight here is that some of it may be out of an application maintainer's hands to fix, and also that even if we can fix it, the "real" fix will hopefully, eventually, come from upstream, so ideally ChromeOS won't become a maintenance burden and either ChromeOS or Qt will support Wayland on the desktop in such a way that this is properly abstracted away.

Most likely, yes. It's great that theres a workaround and you guys replied so fast, so I could continue with steam tinker launcher 🙏

And yea, until Crostini got it's true dedicated vulkan based mesa driver, it's probably a waste of time fiddling with upstream errors.