-
-
Notifications
You must be signed in to change notification settings - Fork 303
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Albert is virtually unresponsive with LightlyShaders enabled (Plasma 6.0.2, Wayland, Arch w/ CachyOS packages) #1375
Comments
Update: Albert just became fully responsive again after a few minutes of waiting.
Nothing from Lightly though. This has happened before. Whenever I log in, Albert apparently ends up becoming very slow and unresponsive for a few minutes, then mysteriously becomes responsive after several minutes have passed, with no relevant log info explaining what happened. I didn't touch Albert's configuration at all, and I already had disabled Albert's file indexing before this login to rule that out. |
Run it with |
I just found out what caused the unresponsiveness — it's the NVIDIA driver, which also caused a seemingly unrelated kernel freeze (usually with no logs on my end) a few minutes after waking my laptop from sleep. |
Looks like the Albert bug is still there, although testing reveals that the unrelated kernel freeze bug appears to be fixed. |
Here is my debug log, although Albert is apparently responsive when I restart it after the login freeze. |
Oh, one more thing — Albert is unresponsive for several minutes whenever it's autostarted by Plasma or launched from a launcher in Plasma, but not when I run it from a terminal. I do pass |
Does it happen when run with xcb from terminal? |
Managed to capture a debug log from an unresponsive instance of Albert. And no, it doesn't happen when invoked from a terminal with |
nothing special in the logs. Can you please adjust the exec line in .config/autostart/albert… to run with -n or --no-load ? just to see if the core and frontend work as expected? |
With |
Here are my enabled plugins:
Note that there was some unresponsiveness when I clicked «Applications» the first time, but not afterward. |
With some sort of binary search you need about 3 reboots to find the plugin causing the issue. 😄 (assuming it is only one of them). reminds me of ddmin. |
like that src |
Uh, I just got something relevant to the issue in KDE's autostart logs for Albert (link expires in 24 hours). Turns out I got a GPU (or GPU driver) error when I closed an unresponsive Albert instance this afternoon. |
Okay, so updating the NVIDIA driver to 550.67 fixed this issue. Here's the relevant change from their changelog:
Which is weird because the Intel iGPU is what's being used for desktop rendering. Then again, the NVIDIA driver was causing a more serious issue (kernel page faults / panics) for me, even though every single time that issue happened, nothing was running on the NVIDIA dGPU. |
Package source
Chaotic-AUR repository
App report
Current Behavior
Whenever I attempt to invoke Albert with the Lightly shaders (and blur variant) enabled on Plasma 6.0.2 running on Wayland on freshly updated Arch (last update was only minutes ago, and I'm using CachyOS Plasma packages), Albert renders at around 0.5 FPS, which is (obviously) unusably slow. Even Albert's configuration dialogue is very sluggish (although it seems to render faster). No other application behaves this way — the rest of the desktop remains perfectly responsive. When I disable the Lightly effects and then restart Albert (and optionally also Plasma), Albert becomes fully responsive again, even when I re-enable the effects after Albert is restarted.
Expected Behavior
Albert should be fully responsive with the Lightly shaders enabled.
Anything else?
journalctl -b 0 | grep -i 'albert'
(with everything from before the current login truncated):journalctl -b 0 | grep -i 'lightly'
:There's no other relevant log info.
The text was updated successfully, but these errors were encountered: