Hi, Am Sonntag, 9. Mai 2021, 22:59:35 CEST schrieb Andrés Barrantes Silman:
That is strange, because the "Full Wayland" session for both is identical (or at least supposed to be). The only difference is that "differentxwl" still offers the "XWayland" session, but by patching Qt (which isn't great).
Apparently it had to do with how the enviroment variables were ordered: if GDK_BACKEND was set to "x11,wayland" it preferred x11, but if it was "wayland ,x11" it went for wayland.
Do you have a link to the upstream reports or have a backtrace?
No, sorry. I could try to troubleshoot a little bit but lack time right now.
Is this using the compose key or just plain dead keys as part of the keyboard layout?
Compose key - this was fixed recently: https://bugs.kde.org/show_bug.cgi?id=411729 https://bugreports.qt.io/browse/QTBUG-87088
Apparently qtwayland had compose key support for a while and it was removed again, but now reintroduced... I submitted qtwayland with the latest changes from the kde patch collection, which includes this fix.
What made the biggest difference?
For me, the fact that Vivaldi, VS Codium and Element were working without touching enviroment variables.
Ah, so probably GDK_BACKEND=wayland.
change the default in qtbase to "wayland;xcb" and drop the "XWayland" session
In the case of GDK_BACKEND, what would happen?
If the concept of having separate sessions for "app compatibility" and "wayland features" is dropped, then setting QT_QPA_PLATFORM and GDK_BACKEND has to be dropped as well. Now with Plasma 5.22 around the corner and the Beta already in KDE:Frameworks5, I'm wondering about the timing of this change. While it might make sense to do this together with the 5.22 update, IMO it's also not great to have too many changes at once. Should this be postponed to around ~5.22.1 time? The TW submission process doesn't easily allow testing 5.22 in parallel with submitting the change to plasma5-workspace-5.21.5. Cheers, Fabian