Environment regularily hanging

I’m not exactly sure when it started, but I’m having some problems with my desktop environment for a few weeks. I’m using KDE with Wayland and everything worked fine in the past.

For example system notifications don’t automatically disappear (the circle around the X just stops sometimes), the widgets (clock, network speed) on my taskbar stop updating, the media keys no longer pause/play stuff and the super key doesn’t open the start menu. The only way to fix this is by manually hovering the cursor over the taskbar. I also noticed that the clock on my lock screen kinda freezes and stops updating until I actively do something. Today I also noticed that I can’t change the volume on Spotify and the cover of the current song isn’t updated until I “fix” it again by hovering over the taskbar.

Any ideas what logs I could check? Is this some kind of energy setting or sleep state? The only messages that I can find in the journal is something about qt.quick.styledtext: StyledText doesn't support entity "#32" (different #numbers) every minute. Thanks.

Most likely from customized settings or widgets. This doesn’t happen ever for me in KDE plasma. I don’t add many custom settings on KDE. Running mostly stock installed system with minor setting changes.

1 Like

Which is weird, because I didn’t nearly customize as much as on my last distro with KDE. I’m even using the default taskbar that Endeavour ships instead of some kind of dock like I did before. Aren’t there any more logs?

What is the hardware? Can you post the link.

inxi -Faz | eos-sendlog

Thanks! Nice hardware Btw! You say that you have default task bar. I see you have aparmor and fish terminal? What other changes or modifications have you made and or widgets are you using? I wonder if it is a font possibly? :thinking:

qt.quick.styledtext: StyledText doesn't support entity "#32"

I found the issue with the qt.quick.styledtext error. It was some old weather widget that I removed. But that didn’t fix the problem. All the modifications you are mentioning already worked for month, so I don’t think that’s the issue. I think we are looking for the needle in the haystack here without some kind of debug log. Maybe I’ll find something eventually or I’ll try X11 again.

Fish is only the user shell, not the system shell so I don’t think that can cause any problems either.

I have the same issue regarding system notifications not automatically disappearing anymore unless you move the mouse over the taskbar.

It started happening sometime in December.

Same thing happens on a fresh Fedora 37 KDE installation (after fully updating it) tho.
So it is not unique to EOS or your installation and most likely a KDE Frameworks / KDE Plasma bug and should be reported on the KDE Bugtracker.

My guess is it will be fixed with the next KDE Frameworks / KDE Plasma Update.

No idea about the rest of your issues tho but I assume they are all symptoms of the same root cause that also causes the issue with the notifications.

Strangely enough there seem to be no issues on my notebook with the same EOS installation and config.

1 Like

Yeah, that’s what I thought. It would be a bit concerning if some regular customizations could affect the whole environment that much.

Ive been running kde for almost 4 years and never ever have these issues. :man_shrugging:

I noticed the same thing with notifications and the taskbar seems to be unresponsive. It does this on both Endeavour installs and a vanilla Arch. It does not do it on my Debian server, but since that thing runs on debian is is probably a year behind for the KDE version. Probably just a KDE bug that will get fixed in an update or two. One thing I have noticed about KDE and Cinnamon is that bugs appear every once in a while, but they are fixed quickly. Gnome on the other hand still uses Unity, a bug that won’t go away!

Do you use AMD driver, right?

I found this thread from Google while searching for fix this issue that started last week.

It’s a recent regression in AMD drivers: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7624

To fix, edit /usr/share/drirc.d/00-mesa-defaults.conf (as root) and append this tag:

    <application name="plasmashell" executable="plasmashell">
        <option name="mesa_glthread" value="false"/>

within the first <device> tag (do not append to the end of the file because this would be the wrong device tag).

Finally, reboot the the system.

1 Like

Looks like that works :+1:

The only problem I have with those “tinkering” solutions: How do I know when the bug is officially fixed and I can remove that setting again? It’s probably not recommended to use that setting forever. In the worst case it could cause more bugs in the future I guess.

This workaround is included in MESA 22.3.3 now, which is in the stable repo as of today. Just update.

I don’t think this will be actually fixed (in MESA or Plasma) in the foreseeable future so that workaround will remain valid for quite a while.

When they fix it they will most likely also remove it from the MESA config. But really, you are not losing anything with glthreading not being enabled in MESA for plasmashell / kwin. In fact that config file is full of workarounds for different applications and games

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.