| Summary: | Nvidia Wayland - KRunner never renders search results | ||
|---|---|---|---|
| Product: | [Plasma] krunner | Reporter: | Wyatt Childers <kdebugs.81do7> |
| Component: | general | Assignee: | Alexander Lohnau <alexander.lohnau> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | alex765, andihartmann, katyaberezyaka, kde, kde, kermit, nate, plasma-bugs, uwu |
| Priority: | NOR | Keywords: | wayland |
| Version: | 5.21.90 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Wyatt Childers
2021-01-24 22:15:11 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 Should say additionally, that krunner hangs and must be killed. Changed product to krunner Problem disappears if krunner is started with -platform xcb (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) In the past I observed the same that krunner just froze, but now it just turns black after resizing It has to do with its resizing behavior, if I fix the size of krunner, it works ocrrectly 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. 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. David, if this is an NVIDIA-specific issue, should we report it to the NVIDIA devs and CC them this bug report? 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). >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.
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 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. 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. |