GNOME only: KeepassXC quirks

[Germano Massullo]

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)

Thank you

[Otto Urpelainen]

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?

Otto

[Robert Marcano]

On 4/30/21 6:23 AM, Germano Massullo wrote:
>  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)
>  
>  Thank you 
The bug about input fields not able to take text input happen 
occasionally on passwords fields on XCA. Switching focus to another 
application and coming back usually workarounds the problem.

[Germano Massullo]

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?

[Robert Marcano]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Vitaly Zaitsev]

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:

[1]: https://bugreports.qt.io/browse/QTBUG-88293
[2]: 
https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/qtbase-use-w...
[3]: https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Germano Massullo]

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:
>
>  [1]: https://bugreports.qt.io/browse/QTBUG-88293
>  [2]:
>
> https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/qtbase-use-w...
>  [3]:
>  https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome
>  
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?

[Hans de Goede]

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:
>  
>  [1]: https://bugreports.qt.io/browse/QTBUG-88293
>  [2]:
> https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/qtbase-use-w...
>  [3]: https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome
>

[Germano Massullo]

Il 30/04/21 16:23, Hans de Goede ha scritto:
>  I tend to agree, it seems this downstream patch breaks at least 3
> apps:
>
>  1. KeepassXC
>  2. calibre
>  3. audacious 
I think also nextcloud-client. I have been receiving bugreports about
quirks on GNOME

[Vitaly Zaitsev]

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-wor...

>  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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Germano Massullo]

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-wor...
>
>
> > 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

[Vitaly Zaitsev]

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:

```c++
#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:

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

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Germano Massullo]

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-wor...
>  
I have a question:
https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-wor...
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

[Germano Massullo]

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-wor...
> >
>  I have a question:
>
> https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-wor...
>  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-w...

[Vitaly Zaitsev]

On 01.05.2021 12:56, Germano Massullo wrote:
>  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 
KDE works fine with the qt-wayland backend. Only Gnome/mutter has major 
issues with this.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Neal Gompa]

On Fri, Apr 30, 2021 at 10:23 AM Hans de Goede <hdegoede(a)redhat.com&gt; wrote:
>  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.
>  
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.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Owen Taylor]

On Sat, May 1, 2021, 7:51 AM Neal Gompa <ngompa13(a)gmail.com&gt; 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

[Neal Gompa]

On Sat, May 1, 2021 at 9:48 AM Owen Taylor <otaylor(a)redhat.com&gt; wrote:
>  On Sat, May 1, 2021, 7:51 AM Neal Gompa <ngompa13(a)gmail.com&gt; 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.
>  
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.

>  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).


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Owen Taylor]

On Sat, May 1, 2021 at 10:09 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Sat, May 1, 2021 at 9:48 AM Owen Taylor <otaylor(a)redhat.com&gt; wrote:
>  >
>  > On Sat, May 1, 2021, 7:51 AM Neal Gompa <ngompa13(a)gmail.com&gt; 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/[e-mail].o...

Owen

[Jonas Ådahl]

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(a)gmail.com&gt;
> wrote:
>  >
>  > On Sat, May 1, 2021 at 9:48 AM Owen Taylor <otaylor(a)redhat.com&gt; 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/[e-mail].o...
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.

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.


Jonas

>  
>  Owen
>

[Jan Grulich]

Hi,

pá 30. 4. 2021 v 12:30 odesílatel Germano Massullo <
germano.massullo(a)gmail.com&gt; napsal:

>  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
>  
I haven't seen any other application having this issue and I've been using
lots of Qt/KDE apps under GNOME. It might be an issue in KeepassXC as they
have some custom theme.


>  https://bugzilla.redhat.com/show_bug.cgi?id=1941731 (CentOS 8)
>  
CentOS doesn't really use Qt Wayland by default.


>  https://bugzilla.redhat.com/show_bug.cgi?id=1954742
>  
Again, can be a KeepassXC issue as any other application I've been using
doesn't have such problem.


>  https://github.com/keepassxreboot/keepassxc/issues/5608
>  
This is the same issue as the first one (about missing focus).

There is only one issue I'm aware of and that's misplaced popups/menus.
There is a bug in Qt opened for it
https://bugreports.qt.io/browse/QTBUG-68636 and it's the only one blocking
upstream decision to switch to Wayland by default. I know that there might
be some other issues in certain apps, but those issues would be really
specific to those apps given their implementation and would need to be
probably fixed case by case. I think it's something I can look into for
Fedora 35, but reverting this change to use xcb by default will result in
not having properly/natively scaled apps in GNOME. Btw. even KDE flatpak
runtime uses Wayland by default on GNOME.

Regards,
Jan

[Jan Grulich]

so 1. 5. 2021 v 17:51 odesílatel Jonas Ådahl <jadahl(a)redhat.com&gt; 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(a)gmail.com&gt; wrote:
>  > >
>  > > On Sat, May 1, 2021 at 9:48 AM Owen Taylor <otaylor(a)redhat.com&gt; 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/[e-mail].o...
>
>  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

[Jan Grulich]

pá 30. 4. 2021 v 13:29 odesílatel Otto Urpelainen <oturpe(a)iki.fi&gt; 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

[David Tardon]

Hi,

On Sat, 2021-05-01 at 21:10 +0200, Jan Grulich wrote:
>  
>  so 1. 5. 2021 v 17:51 odesílatel Jonas Ådahl <jadahl(a)redhat.com&gt;
>  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(a)gmail.com&gt;
>  > wrote:
>  > > > 
>  > > > On Sat, May 1, 2021 at 9:48 AM Owen Taylor <otaylor(a)redhat.com&gt;
>  > 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/[e-mail].o...
>  > 
>  > 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.  
I see something similar in calibre. A simple reproducer:

1. Open "Edit metadata" dialog.
2. Click on the Rating listbox.
3. Click into any text field. Text cursor is in the text field but
input doesn't work.
(4.) After expanding any combobox (e.g., Tags), text cursor is in that
combobox and input works again.

D.

[Otto Urpelainen]

Jan Grulich kirjoitti 1.5.2021 klo 22.15:
> >
> > 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.
>   
Ok, great to hear that the situation is better than what I thought. In 
that case, I will try to dig a bit deeper into the issue .

Otto

[Germano Massullo]

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:
>
>  ```c++
>  #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:
>
>  ```c++
>  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

[Germano Massullo]

Il 01/05/21 21:01, Jan Grulich ha scritto:
>  Hi,
>
>  pá 30. 4. 2021 v 12:30 odesílatel Germano Massullo
>  <germano.massullo(a)gmail.com <mailto:[e-mail]>> napsal:
>
>      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=1925130>
>
>
>  I haven't seen any other application having this issue and I've been
>  using lots of Qt/KDE apps under GNOME. It might be an issue in
>  KeepassXC as they have some custom theme. 
Not KeePassXC bug because:
- as I said, upstream devels confirmed that all strange quirks
bugreports they are receiving since a while, are from Fedora GNOME
(Wayland) only
- I received various feedbacks [1] [2] of problems disappearing as soon
I introduced this patch
https://src.fedoraproject.org/rpms/keepassxc/blob/rawhide/f/xcb.patch

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1925130#c13
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1954742#c10

[Germano Massullo]

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

[Germano Massullo]

This problem should have been fixed with commit
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=dda7dab8274991e4a61a97c3...
after checking which Qt version includes such commit, I will remove 
xcb.patch [1] and release a new keepassxc release to test its behaviour

[1]: https://src.fedoraproject.org/rpms/keepassxc/blob/rawhide/f/xcb.patch

[Germano Massullo]

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=dda7dab8274991e4a61a97c3...
>
>
>  after checking which Qt version includes such commit, I will remove 
>  xcb.patch [1] and release a new keepassxc release to test its behaviour
>
>  [1]: 
>  https://src.fedoraproject.org/rpms/keepassxc/blob/rawhide/f/xcb.patch 
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