Setting this to the correct component.

I would prefer if all these issues are identified and fixed, rather then reverting a change which is not a fix at all. Some issues might be in Mutter, some might be in Qt, but they need to be investigated and not workarounded. This very same change is also used in KDE runtime from Flathub so even Qt apps from Flathub use Wayland backend by default.

The only issue I could see sometimes with all possible KDE/Qt apps I've been using in GNOME is misplaced popups, but that's a known issue. This was also the only blocker when I proposed this change upstream [1].

Also, going back this way all Qt apps won't scale properly and be blurry.

My proposal would be to collect all issues, create a tracker for them and try to fix them for Fedora 35. If we don't manage to do that and all issues will be Qt ones, we can discuss going back, but it would be after we tried. If we do it immediately, things won't get fixed and issues will remain hidden until the switch happens in upstream.

[1] - https://bugreports.qt.io/browse/QTBUG-68619.

There is also bug 1957503 which, according to my testing, affects all Qt applications in (Fedora, Gnome, Wayland) combination. I have also reported it upstream [1].

[1]: https://bugreports.qt.io/browse/QTBUG-93474

I also initially thought that the best way forward would be to just disable Wayland for Qt. Since then, I have realized that there is the path of fixing things in Qt 6, backporting to Qt 5 through KDB backports repository and applying them to Fedora's Qt 5. Being so, I have changed my mind and support keeping Wayland enabled, reporting the issues that are discovered and contributing fixes if skill and time allow.

The Fedora way, as I understand it, is to enable new technology and deal with the bugs, rather than staying with the old tech indefinitely to avoid them.

I would like to get Wayland on Qt working. Because of that, I have thought about taking a look at Qt code regarding bug 1957503. That will be a slow process, because I have no previous experience on Qt codebase. So, if a tracker is started and some unclear bugs are added to it, I could also try to analyze them and create minimal reproducers and so on.

I opened a tracker for Qt Wayland issues: https://bugzilla.redhat.com/show_bug.cgi?id=1965576

+1 for reversion because it creates more problems than it solves. I used to patch a lot of packages to force the XCB backend on Wayland due to complaints from Gnome 3 users: goldendict, ksnip, flameshot, etc.

> I would prefer if all these issues are identified and fixed, rather then reverting a change which is not a fix at all.

The projects upstreams are not interested in fixing Fedora-specific issues, because "it works fine in Ubuntu".

> If we do it immediately, things won't get fixed and issues will remain hidden until the switch happens in upstream.

Why would Fedora developers need to fix all such regressions in downstream? I'm not paid for this job.

> This very same change is also used in KDE runtime from Flathub so even Qt apps from Flathub use Wayland backend by default.

Some applications force the XCB backend in their manifest.

> Also, going back this way all Qt apps won't scale properly and be blurry.

Everything works like a charm after forcing XCB backend (XWayland). Qt apps in KDE works fine even with fractional scaling factor. I use 150% on my laptop.

Qt 5 is now a proprietary software (version 5.15.3+) and will receive no patches/fixes.

(In reply to Vitaly Zaitsev from comment #5)
> +1 for reversion because it creates more problems than it solves. I used to
> patch a lot of packages to force the XCB backend on Wayland due to
> complaints from Gnome 3 users: goldendict, ksnip, flameshot, etc.
> 

Have you reported any issue you identified as a bug in qt5-qtwayland? 

> > I would prefer if all these issues are identified and fixed, rather then reverting a change which is not a fix at all.
> 
> The projects upstreams are not interested in fixing Fedora-specific issues,
> because "it works fine in Ubuntu".
> 
> > If we do it immediately, things won't get fixed and issues will remain hidden until the switch happens in upstream.
> 
> Why would Fedora developers need to fix all such regressions in downstream?
> I'm not paid for this job.
 
There are people in Fedora who actually contribute to Qt upstream (me included). I don't want YOU specifically to jump and fix issues in qtwayland.

> 
> Qt 5 is now a proprietary software (version 5.15.3+) and will receive no
> patches/fixes.

You are wrong, patches still go into Qt 5.15 and are backported to KDE's Qt patch collection where distributions pick them up to their packages.

> Have you reported any issue you identified as a bug in qt5-qtwayland? 

The Qt upstream doesn't support running native Wayland backend on GNOME even in pre Qt 6.2 (dev branch): https://github.com/qt/qtbase/blob/dev/src/gui/kernel/qguiapplication.cpp#L1407

Why should we? We are not getting paid for this job.

> There are people in Fedora who actually contribute to Qt upstream (me included). I don't want YOU specifically to jump and fix issues in qtwayland.

But I need to patch my packages in downstream and maintain those fixes.

> You are wrong, patches still go into Qt 5.15 and are backported to KDE's Qt patch collection where distributions pick them up to their packages.

Even Qt 6.x dev hasn't fixed these issues yet.

> This very same change is also used in KDE runtime from Flathub so even Qt apps from Flathub use Wayland backend by default.

https://github.com/flathub/com.kristianduske.TrenchBroom/blob/98a3b8a6e55ccbf1a44771d8a099d30622c07d3e/com.kristianduske.TrenchBroom.json#L12
https://github.com/flathub/org.kde.kolourpaint/blob/0527e34fabb41cba37c6707ee107e97556ee762a/org.kde.kolourpaint.json#L14
https://github.com/flathub/com.chatterino.chatterino/blob/18e03ca830f28ea876dae6507c26e5f1cbfb9cec/com.chatterino.chatterino.yml#L14
https://github.com/flathub/org.openhantek.OpenHantek6022/blob/6fa7f8c357fc0573f64aed6e6e5de5e28d04427b/org.openhantek.OpenHantek6022.yml#L15
https://github.com/flathub/com.rosegardenmusic.rosegarden/blob/8ac254753f6e7b29413ae30f03a6ef621461c289/com.rosegardenmusic.rosegarden.json#L13
https://github.com/flathub/org.electrum.electrum/blob/7a3867719cb20ee22e7c3ef8847dc57b2360f7ff/org.electrum.electrum.json#L10
https://github.com/flathub/com.github.fontmatrix.Fontmatrix/blob/49fdebbf009bc336f5c19417b818783ed5a53421/com.github.fontmatrix.Fontmatrix.json#L16
https://github.com/flathub/uk.org.zint.zint-qt/blob/f6c30cfe2858bada7785ae73284644858a583cf0/uk.org.zint.zint-qt.yaml#L15
https://github.com/flathub/org.avidemux.Avidemux/blob/75ffac52c85cc1ceb105992f4581fe0469194139/org.avidemux.Avidemux.yaml#L11
https://github.com/flathub/org.dash.electrum.electrum_dash/blob/fdad9ec436cf6ed92a2cd13b331566c1131d0a78/org.dash.electrum.electrum_dash.json#L10
https://github.com/flathub/org.hydrogenmusic.Hydrogen/blob/425efc134dfa9f3fae189792e21e5ae060815e74/org.hydrogenmusic.Hydrogen.json#L14
https://github.com/flathub/org.musescore.MuseScore/blob/c2a2f112f34538c2e59b20cba74a53a0c329bd16/org.musescore.MuseScore.yaml#L21
https://github.com/flathub/io.lmms.LMMS/blob/1a7c3f8780794c2fd3d088a24ac12f9398d08b7c/io.lmms.LMMS.json#L19
https://github.com/flathub/org.kde.okular/blob/7e4f34ccf6e86eaf3f42222ad57ec3747aa9e1f9/org.kde.okular.json#L15
https://github.com/flathub/net.scribus.Scribus/blob/9f6bebb19e525242437583d376f436aa0ba253ce/net.scribus.Scribus.yaml#L23
https://github.com/flathub/org.mixxx.Mixxx/blob/da784e9b76cb1c304401164899d8fe6ad350d8d3/org.mixxx.Mixxx.yaml#L16
https://github.com/flathub/org.freecadweb.FreeCAD/blob/abbc05c0ff45d3e59f7581edf03339a767444a0f/org.freecadweb.FreeCAD.yaml#L10
https://github.com/flathub/org.kde.kontact/blob/2d277bd9054141b831e02ebe72ffc1c601d65cc7/org.kde.kontact.json#L49

Apps like video/audio editors, painting apps, apps using qtwebengine or apps using heavily custom UI will need to get fixed by their upstream and get proper Wayland support, until then they need to carry patches to avoid using it, but THIS shouldn't block using Wayland by default. Blocking on every single app, then we would never make the switch. However, apps like Keepassxc have issues which can be fixed either in Mutter or QtWayland.

> Apps like video/audio editors, painting apps, apps using qtwebengine or apps using heavily custom UI will need to get fixed by their upstream and get proper Wayland support, until then they need to carry patches to avoid using it, but THIS shouldn't block using Wayland by default.

The upstreams are not interested in fixing Fedora-specific issues, because "it works fine in Ubuntu". Example: https://github.com/ksnip/ksnip/issues/416

> Blocking on every single app, then we would never make the switch.

I just need the application to work fine in all available DEs without crashes. I used to get a lot of crash reports from Gnome 3 users related to Wayland.

(In reply to Vitaly Zaitsev from comment #10) 
> The upstreams are not interested in fixing Fedora-specific issues, because
> "it works fine in Ubuntu". Example: https://github.com/ksnip/ksnip/issues/416

Vitaly,

I understand you pain when packages you maintain are hit by bugs because of a Fedora Change. In my opinion, in cases where the application simply becomes unusable, overriding defaults makes sense.

However, I read the ksnip issue you link differently than you do. Certainly the ksnip developers are doing everything they can to fix the issue. When it becomes clear that the problem is not in ksnip but in Qt, they report it in the Qt issue tracker and *the problem is eventually fixed*, even in Qt 5. For me, that issue is a good example why we should report issues and help upstream to analyze and fix them.

Have you tried reverting xcb override for ksnip package? To me it seems it is not needed because of that bug anymore.

You also mention that there are multiple other applications with similar problems. Could you link to the relevant issues or give other details? Note that filling the tracker bug with the known problems is a good idea even if you are already convinced that disabling Wayland on Qt is the way to go. Certainly an accurate list of reproducible bugs is a better argument than a vague assertion that nothing works.

(In reply to Otto Urpelainen from comment #11)
> (In reply to Vitaly Zaitsev from comment #10) 
> > The upstreams are not interested in fixing Fedora-specific issues, because
> > "it works fine in Ubuntu". Example: https://github.com/ksnip/ksnip/issues/416
> 
> Have you tried reverting xcb override for ksnip package? To me it seems it
> is not needed because of that bug anymore.

I will answer my own question: No, ksnip still does not work without disabling. Issue 416 you link does not happen anymore, but there are many other problems: ksnip windows becomes invisible after taking a new screenshot, pasting to certain applications (e.g. LibreOffice) still does not work, for multi-monitor wrong and/or corrupted screen are is saved.

These should be investigated better. I try to get to it soon.

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release.

Thank you for reporting this bug and we are sorry it could not be fixed.