After updating my system and an particular application, Zoom, the application crashes immediately on start and reports problems with Wayland. But, I’m running GNOME on Xorg, not Wayland. The app also reports that it’s trying Wayland because QT_QPA_PLATFORM is set to ‘wayland’.
If I unset that env var, the app starts as it used to on the previous version. But, I don’t understand why QT_QPA_PLATFORM is set to ‘wayland’ because XDG_SESSION_TYPE is set to ‘x11’.
I never tracked this env var before, so maybe it changed recently, too; I don’t even know how long this has been set this way under Xorg. Also, I don’t see Xwayland running, so, it’s not as though ‘GNOME on Xorg’ is running some hybrid system. (What happend to Xwayland? Is it depreciated now?) I don’t understand who is setting QT_QPA_PLATFORM, but it’s not me, and it seems wrong, doesn’t it?
The problem is the native application. (I actually have both installed because the native app crashes and I was desperate, so I tried the flatpak version. The flatpak version doesn’t report any “overrides”, according to the command you suggested.)
But, I don’t understand your point about ‘env’. That’s how I got the information to start this thread. ‘env’ says what I reported. My question was why is this getting set this way?
Hi, I guess may be it set by other QT base app installed in your system and since Zoom it self (as far as I know) uses QT, may be mistakenly read the configuration.
XWayland only working on Wayland session as backward compatibility for apps that not support Wayland session.
Hi, I guess may be it set by other QT base app installed in your system and since Zoom it self (as far as I know) uses QT, may be mistakenly read the configuration.
Hmm, can you elaborate? I don’t see how this would work. How would a QT app that is installed set a global QT env var? I mean, this variable isn’t selecting a QT option that some app wants, it’s telling all QT apps what options are available. In any case, that would still be the wrong setting, right?
Perhaps a better question would be: How do I identify the cause of this setting? How do I find the culprit?
XWayland only working on Wayland session as backward compatibility for apps that not support Wayland session.
Okay, yeah. I wasn’t thinking it through. XWayland is an X11 server. So, on Xorg, there isn’t any need to run XWayland. So, it makes sense XWayland isn’t running.
Have you already checked .bash_profile or .bashrc or the configuration files of the shell you’re using?
Yes. I’ve tried very hard to do that and I haven’t found it, yet. But I don’t think that’s right. AFAICT, GNOME session doesn’t source that stuff. I’m researching now, but I guess I never had to learn what GNOME session was doing about env, before now. Under X11, GDM would start your profile first.
Yeah, okay. I cannot believe it took me so long to find. I had no memory of it, but I set this manually for a specific application that asked for it a while ago. This profile proliferated to other systems, but there was no logic for the possibility of the Xorg env. Embarrassing. Sorry for the trouble.