pá 30. 4. 2021 v 13:29 odesílatel Otto Urpelainen oturpe@iki.fi napsal:

Germano Massullo kirjoitti 30.4.2021 klo 13.23:

...

KeepassXC comaintainer here.

There are many Fedora GNOME Wayland users experiencing quirks in using KeepassXC. Textboxes not showing text that is being written, other quirks with GNOME, etc.

Upstream developers said many times that this only happen with Fedora

users.

...

Myself I do use KDE Spin and I do not experience these issues (tested on Wayland too)

I don't paste bugs titles since they are misleading

https://bugzilla.redhat.com/show_bug.cgi?id=1925130

https://bugzilla.redhat.com/show_bug.cgi?id=1941731 (CentOS 8)

https://bugzilla.redhat.com/show_bug.cgi?id=1954742

https://github.com/keepassxreboot/keepassxc/issues/5608

plus others that I cannot find again at the moment

I would like to ask if you have any idea about why this happens on GNOME only (and not on other distros too)

Octave is suffering from similar problems. I have reported this:

https://bugzilla.redhat.com/show_bug.cgi?id=1954181

and also saw another issue where menus opened in strange places on the screen, or even partially off-screen. I did not report that yet, because I do know how to reproduce reliably.

The best assumption I could produce was simply that Qt5 and Wayland do not play well together. Maybe Gnome also needs to be involved. Is there a distribution that has that combination, but does not have these problems?

As far as I know, Qt 5 reached end of life when Qt 6 came out. To me it seems unlikely that remaining Qt 5 Wayland problems will ever get fixed. Is there some downside to forcing XWayland through QT_QPA_PLATFORM=xcb for Qt 5 applications with problems on Wayland?

That's not true. Fixes are still happening in 5.15 and there is even a public repository for Qt 5.15 in KDE's Gitlab instance. Also, given that Qt6 is not really different from Qt5 that much (at least in QtWayland), then all fixes in Qt6 are easily backportable to Qt5, which is something I do quite often.

Jan

On 4/30/21 8:17 AM, Germano Massullo wrote:

Il 30/04/21 14:11, Robert Marcano via devel ha scritto:

...

The bug about input fields not able to take text input happen occasionally on passwords fields on XCA.

What is XCA?

Another Fedora package that uses QT

https://hohnstaedt.de/xca/

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

Il 30/04/21 15:33, Vitaly Zaitsev via devel ha scritto:

On 30.04.2021 12:23, Germano Massullo wrote:

...

There are many Fedora GNOME Wayland users experiencing quirks in using KeepassXC. Textboxes not showing text that is being written, other quirks with GNOME, etc.

There are a lot of issues with Mutter and Qt5[1]. That's why the Qt upstream forces XCB backend for the Gnome 3, but Fedora removes it in downstream[2], as approved by the system-wide proposal[3].

Please try the following: QT_QPA_PLATFORM=xcb /usr/bin/keepassxc

I think this downstream patch should be dropped from Fedora.

See also:

Thank you so much Vitaly, your infos are very precious. Many users reported to have fixed their problems by using xcb platform. Could you please suggest me how I could implement a patch? Would you do it in the .desktop file?

Il 30/04/21 19:11, Vitaly Zaitsev via devel ha scritto:

On 30.04.2021 16:09, Germano Massullo wrote:

...

Could you please suggest me how I could implement a patch?

https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workar...

...

Would you do it in the .desktop file?

Patching desktop file is not a good idea. It can break lots of things and custom themes.

Let's wait also for Jan Grulich. He should be back next days/weeks

Il 01/05/21 12:40, Vitaly Zaitsev via devel ha scritto:

On 01.05.2021 11:44, Germano Massullo wrote:

...

Let's wait also for Jan Grulich. He should be back next days/weeks

Yes, but my simple workaround works fine. We need to add a new method:

#ifdef Q_OS_LINUX
void wayland_hacks()
{
    // Workaround to https://github.com/ksnip/ksnip/issues/416
    QByteArray currentDesktop = qgetenv("XDG_CURRENT_DESKTOP").toLower();
    QByteArray sessionDesktop = qgetenv("XDG_SESSION_DESKTOP").toLower();
    QByteArray sessionType = qgetenv("XDG_SESSION_TYPE").toLower();
    if (sessionType.contains("wayland") &&
(currentDesktop.contains("gnome") || sessionDesktop.contains("gnome")))
    {
        qputenv("QT_QPA_PLATFORM", "xcb");
    }
}
#endif

Then call it in main(), just before the QApplication initialization:

int main(int argc, char** argv)
 {
#ifdef Q_OS_LINUX
    wayland_hacks();
#endif
    QApplication app(argc, argv);
}

https://src.fedoraproject.org/rpms/keepassxc/blob/rawhide/f/xcb.patch https://bodhi.fedoraproject.org/updates/?packages=keepassxc Any KeePassXC karma feedback is welcomed

Il 01/05/21 12:56, Germano Massullo ha scritto:

Il 30/04/21 19:11, Vitaly Zaitsev via devel ha scritto:

...

On 30.04.2021 16:09, Germano Massullo wrote:

...

Could you please suggest me how I could implement a patch?

https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workar...

I have a question: https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workar... wouldn't be better to remove the reference to gnome? So that it the patch will work for all Wayland sessions, like KDE Plasma, etc? Since the root problem is on Qt not the specific desktop environment

My fault, I did not notice that the downstream qt patch was gnome oriented https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/qtbase-use-wayl...

Hi,

On 4/30/21 3:33 PM, Vitaly Zaitsev via devel wrote:

On 30.04.2021 12:23, Germano Massullo wrote:

...

There are many Fedora GNOME Wayland users experiencing quirks in using KeepassXC. Textboxes not showing text that is being written, other quirks with GNOME, etc.

There are a lot of issues with Mutter and Qt5[1]. That's why the Qt upstream forces XCB backend for the Gnome 3, but Fedora removes it in downstream[2], as approved by the system-wide proposal[3].

Please try the following: QT_QPA_PLATFORM=xcb /usr/bin/keepassxc

Ah interesting, I use calibre regularly under a GNOME3 wayland sessions and I have noticed some weird issues there too, like the "completion" pop-ups for things like the Author and Series fields which allow you to select an Author / Series already used for other books showing up in completely the wrong places, as well as right-click context(sub)menus also showing up in completely the wrong places too.

I also use the audacious media-player for music in its x11amp compatible skinned mode and that is has serious issues when used without QT_QPA_PLATFORM=xcb under GNOME3. I thought this was just a special case because of the skinned UI, but I now see that it is part of a wider pattern.

I was going to write the following here:

""" I can understand if the KDE SIG wants to use Wayland by default when running a KDE Wayland session, but under GNOME3 this indeed seems like a bad idea for now.

Maybe instead the QT_QPA_PLATFORM environment option can be set in the KDE wayland session, so that Wayland is used there while leaving GNOME3 alone ? """

Which seems like a reasonable compromise to me, but then I looked at the patch from [2] and it seems that that is the upstream default and the Fedora packages are actually overriding this sensible upstream default.

I think this downstream patch should be dropped from Fedora.

I tend to agree, it seems this downstream patch breaks at least 3 apps:

1. KeepassXC 2. calibre 3. audacious

And I have a feeling it breaks all Qt apps to at least some extend, now the changes process page [3] does list a couple of reasons why this is necessary, but I just checked and calibre looks fine with the mutter provided window decorations for X11 windows instead of using CSD, so this does not seem like a strong argument.

I can understand that it is desirable to make this change, but it seems that QT5 just is not completely ready for this yet. For me the patch[2] breaks 2/2 Qt apps which I regularly used, so it seems that it would be best to drop this downstream modification for now.

Regards,

Hans

See also:

On 30.04.2021 16:23, Hans de Goede wrote:

Maybe instead the QT_QPA_PLATFORM environment option can be set in the KDE wayland session, so that Wayland is used there while leaving GNOME3 alone ?

KDE Wayland already uses native qt-wayland backend. No changes needed.

I tend to agree, it seems this downstream patch breaks at least 3 apps:

4. goldendict (patched in upstream). 5. ksnip (patched in downstream). 6. flameshot (patched in upstream).

I can understand that it is desirable to make this change, but it seems that QT5 just is not completely ready for this yet. For me the patch[2] breaks 2/2 Qt apps which I regularly used, so it seems that it would be best to drop this downstream modification for now.

That's why this downstream patch should be dropped, IMO.

On Sat, May 1, 2021, 7:51 AM Neal Gompa ngompa13@gmail.com wrote:

Note it only looks fine as long as you're not using fractional scaling. Once framebuffer/fractional scaling is enabled in Mutter, it looks absolutely terrible, because X11 applications are not scaled properly. There are also other glitches if Qt5 applications run as X11 apps, and I'm not sure if some prominent Qt5 applications expose the correct functionality in X11 mode (e.g. OBS Studio uses PipeWire for screencasting when it is in Wayland mode).

In general, I'd like to see if we can figure out *why* Mutter isn't doing the right thing for Qt applications and why they're breaking this way, because the fact that they're fine in Plasma Wayland and not on GNOME Wayland points to Mutter needing work here.

That doesn't make any more logical sense than "the fact that GTK applications work fine with Mutter points to Qt needing work here." Without a diagnosis, it's impossible to say.

If we can put someone who understands Qt together with someone who understands Mutter it should be possible to figure out what is going on. If the fix is hard, then reverting the Qt change until F35 might be needed, but patching a reversion to X into Qt apps one-by-one doesn't seem like something we'd want to do: it would leave unpatched apps affected, we might forget to remove some of the patches, and it's going to make things altogether more confusing.

Owen

On Sat, May 1, 2021 at 10:09 AM Neal Gompa ngompa13@gmail.com wrote:

On Sat, May 1, 2021 at 9:48 AM Owen Taylor otaylor@redhat.com wrote:

...

On Sat, May 1, 2021, 7:51 AM Neal Gompa ngompa13@gmail.com wrote:

...

In general, I'd like to see if we can figure out *why* Mutter isn't doing the right thing for Qt applications and why they're breaking this way, because the fact that they're fine in Plasma Wayland and not on GNOME Wayland points to Mutter needing work here.

That doesn't make any more logical sense than "the fact that GTK applications work fine with Mutter points to Qt needing work here." Without a diagnosis, it's impossible to say.

GTK applications work fine on KWin (modulo some missing Wayland protocols not being implemented in GTK3), so I'm reasonably confident that the problem is in Mutter.

How is that relevant? Qt is making some assumptions about the compositor behavior which don't hold with mutter - and we don't know whether it's Qt relying on things that accidentally work with Kwin, or Mutter not properly implementing parts of the Wayland protocol that GTK doesn't use. [roughly speaking ... not comprehensively listing all possibilities]

...

If we can put someone who understands Qt together with someone who understands Mutter it should be possible to figure out what is going on. If the fix is hard, then reverting the Qt change until F35 might be needed, but patching a reversion to X into Qt apps one-by-one doesn't seem like something we'd want to do: it would leave unpatched apps affected, we might forget to remove some of the patches, and it's going to make things altogether more confusing.

I agree, do we know anyone who understands Mutter that could work with someone who understands Qt to figure this out? I've got a couple of folks in mind who could help on the KDE side (who I've CC'd to this email).

Added Jonas Adahl (all things output), Carlos Garnacho (all things input) and Oliver Fourdan (compat problems expert) to the Cc:- one of them should be able to help.

Since the context is trimmed, the thread here is: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...

Owen

so 1. 5. 2021 v 17:51 odesílatel Jonas Ådahl jadahl@redhat.com napsal:

On Sat, May 01, 2021 at 10:49:57AM -0400, Owen Taylor wrote:

...

On Sat, May 1, 2021 at 10:09 AM Neal Gompa ngompa13@gmail.com wrote:

...

On Sat, May 1, 2021 at 9:48 AM Owen Taylor otaylor@redhat.com wrote:

I agree, do we know anyone who understands Mutter that could work with someone who understands Qt to figure this out? I've got a couple of folks in mind who could help on the KDE side (who I've CC'd to this email).

Added Jonas Adahl (all things output), Carlos Garnacho (all things input) and Oliver Fourdan (compat problems expert) to the Cc:- one of them should be able to help.

Since the context is trimmed, the thread here is:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...

I have yet to find any recent bugs in mutter that causes issues that happens only with Qt; last time I and Jan debugged some issues with Dolphin and Kate resizing wierdly, there were still some Qt issues with incorrectly committed surface state. I think he is still looking into those.

Yes, still working on those, but I don't think this issue is relevant here. And I would really like to know whether the "unable to type... " issue is KeepassXC only thing, because so far I haven't seen it and didn't get any other report.

Some issues likely doesn't cause issues on kwin because kwin takes over window decoration from Qt applications, meaning Qts inability to commit correct state is papered over by the incorrect intermediate state not existing, but for example oddly placed menus (that I have seen and can reproduce) behave exactly the same in e.g. weston as in mutter.

That's a Qt issue, a known one, and it's probably about time to finally fix it for good so once I fix the resizing issue, I think I can look into this one as well.

Jan

I opened ticket "revert Qt Wayland By Default On Gnome" https://bugzilla.redhat.com/show_bug.cgi?id=1965539

Il 24/02/22 00:25, Germano Massullo ha scritto:

This problem should have been fixed with commit https://code.qt.io/cgit/qt/qtbase.git/commit/?id=dda7dab8274991e4a61a97c352d...

after checking which Qt version includes such commit, I will remove xcb.patch [1] and release a new keepassxc release to test its behaviour

In the previously mentioned Qt code URL, there is a "Pick-to: 6.2" attribute that means that it has been included only in Qt >= 6.2. Therefore the bug is very likely to be still present in all applications that use Qt 5