Bug 432062 - Nvidia Wayland - KRunner never renders search results
Summary: Nvidia Wayland - KRunner never renders search results
Status: RESOLVED UPSTREAM
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: 5.21.90
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Alexander Lohnau
URL:
Keywords: wayland
Depends on:
Blocks:
 
Reported: 2021-01-24 22:15 UTC by Wyatt Childers
Modified: 2023-11-20 16:13 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wyatt Childers 2021-01-24 22:15:11 UTC
SUMMARY
Using an nvidia wayland session, krunner never reports the results of a search.

STEPS TO REPRODUCE
1. Start a nvidia wayland session in a multimonitor setup
2. Open krunner
3. Search for something (e.g. firefox)

OBSERVED RESULT
Krunner seemingly does nothing and the rendering of the entered search term truncates.
i.e. it seems to stop rendering after quickly getting its search results, never displaying them.

EXPECTED RESULT
Krunner quickly populates a list of rendered search results as it would under X11.
Comment 1 Andreas Hartmann 2021-05-24 06:36:04 UTC
Exactly same problem here. When starting krunner on the konsole, you can see the following output:
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

It's on Leap 15.2 using actual KDE / X packages:
plasma5-workspace 5.21.90
nvidia 460.80
kwayland-5.82.0-lp152.228.2.x86_64
libqt5-qtwayland-5.15.2-lp152.5.1.x86_64
xwayland-21.1.1-lp152.4.3.x86_64
Comment 2 Andreas Hartmann 2021-05-24 06:36:51 UTC
Should say additionally, that krunner hangs and must be killed.
Comment 3 Andreas Hartmann 2021-05-26 04:22:16 UTC
Changed product to krunner
Comment 4 Andreas Hartmann 2021-05-26 04:23:19 UTC
Problem disappears if krunner is started with -platform xcb
Comment 5 Arek Guzinski 2021-07-29 09:45:30 UTC
(In reply to Andreas Hartmann from comment #2)
> Should say additionally, that krunner hangs and must be killed.

I'm having the issue as originally described, too. But I don't have to kill krunner.

I suspect the original description is a duplicate of #427921, but yours could be a different bug.


For reference, my system is:
Operating System: KDE neon 5.22
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.3
Kernel Version: 5.8.0-63-generic (64-bit)
Processors: 4 × Intel® Core™ i5-6500 CPU @ 3.20GHz
Memory: 15,6 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 (Driver: 470.57.02)
Comment 6 David Redondo 2021-08-04 13:28:47 UTC
In the past I observed the same that krunner just froze, but now it just turns black after resizing
Comment 7 David Redondo 2021-08-04 14:40:31 UTC
It has to do with its resizing behavior, if I fix the size of krunner, it works ocrrectly
Comment 8 David Redondo 2021-08-05 11:34:23 UTC
Actually seems like every window is affected by this, if it's resized it stops doing anything (but can be interacted with).

In the wayland log I see a new buffer is created but never attached to the surface.
Comment 9 David Edmundson 2021-08-06 10:13:53 UTC
As a workaround please run kcmshell5 qtquicksettings and select the basic render loop.

This proves it to be a client issue. (Either Qt or Nvidia)

Interestingly we can also make it work by putting a breakpoint on the wl_surface_commit and holding down enter in gdb - enough to slow things down enough.

In theory Qt never resizes a buffer whilst we're rendering, but clearly things are subtly different on nvidia and we can get it in a broken state.
Comment 10 Nate Graham 2021-08-06 13:38:57 UTC
David, if this is an NVIDIA-specific issue, should we report it to the NVIDIA devs and CC them this bug report?
Comment 11 Andreas Hartmann 2021-08-07 17:05:30 UTC
The workaround fixes some other, similar problems w/ other plasma / KDE programs, like the application menu, e.g., too. 

But that's anyway not enough to use it, because other programs, like Firefox e.g., don't work, too (ESR and actual version). You have to force them to run in Xwayland - but there are problems with the clipboard (you always have to CTRL-C to copy to clipboard - that's annoying).
Comment 12 David Edmundson 2021-08-07 23:37:59 UTC
>David, if this is an NVIDIA-specific issue, should we report it to the NVIDIA devs and CC them this bug report?

Yes, but we can't expect upstream to inspect krunner. 

Before reporting to upstream we need to make a reproducible minimal test case ideally without even any Qt to demonstrate the problem. (and to confirm it's not our bug in Qt!)

As for the comments about clipboard or other apps, lets not derail this thread with other issues.
Comment 13 Nate Graham 2021-08-31 20:13:34 UTC
Git commit 66c5bb0efa6ac2a9a7bef8a4776150fdaf129353 by Nate Graham, on behalf of David Redondo.
Committed on 31/08/2021 at 20:12.
Pushed by ngraham into branch 'master'.

qtquicksettings: Add workaround for Nvidia Wayland

If using threaded rendering on wayland, QtQuick windows stop
working when they are resized. As a workaround we can use the
basic render loop.
See also QTBUG-95817.

M  +24   -9    src/quickaddons/qtquicksettings.cpp

https://invent.kde.org/frameworks/kdeclarative/commit/66c5bb0efa6ac2a9a7bef8a4776150fdaf129353
Comment 14 Arek Guzinski 2021-10-15 09:29:57 UTC
I still have a small problem with accepting the bug as resolved ...

When logging in as "tmp" - a testing user with it's home on a tmpfs, so I get the default config, the workaround works.

But when I logged in as myself, it did not.

With a status of resolved, I would expect either an automatic activation, or a dialog on login, that offers me to apply the workaround (you can't expect a non-technical user to fix this any other way!), but nothing like that happens.

Then again, you mention qtquicksettings - which I was able to start via krunner in an X11-session (but NOT via systemsettings! - another bug?) and will try the wayland session again after writing this.
For the record: Rendering Backend was set to OpenGL, but Render Loop was Automatic.

I'll leave it up to you plasma-devs if you want to reopen the bug because of this or not.
Comment 15 David Redondo 2021-10-19 07:17:29 UTC
Hmm maybe we are missing creating the context in this case but a normal user should never modify nor access this kcm anyways. And if you know what you are doing you can go back to either automatic or select "Basic" yourself.

It's RESOLVED UPSTREAM not because it is fixed, but because it's not a KDE bug but an upstream one.