[SOLVED] KDE Plasma 5: Windows can not be moved off screen

[c00l.wave]

I'm used to freely move my windows around using Alt/Meta + Drag in KDE Plasma 5 and I am pretty sure I was able to move them out the top and left edges of my screen. Somehow, after a recent update (or some configuration change that I'm not aware of), that's no longer possible. I can only move them out to the right or bottom but they get stuck when the top-left window corner hits the top/left screen edges.

Does anyone know what changed and how I can restore the old behaviour?

[asturm]

https://bugs.kde.org/show_bug.cgi?id=469426

[c00l.wave]

Thanks; sounds like it's some difference between target architectures in GCC? I've changed from an old Intel i7 to a modern Ryzen and as part of profile changes recompiled the entire system with -march=znver4 recently which in the bug comments is suspected to cause that (and potentially other) issues through AVX512 instructions.

Is there some way to define a different -mtune GCC flag per ebuild to only (and always) compile kwin/Plasma without those AVX instructions as a workaround? It's unlikely that there will be any bugfix for Plasma 5 as it is EOL (but I have doubts that Plasma 6 is already equal to Plasma 5 in terms of features and usability, having gone through all the previous KDE major releases).

Edit: Found it: https://wiki.gentoo.org/wiki//etc/porta ... ic_package

1. create a .conf suffixed file in /etc/portage/env/ to hold the override (both CFLAGS and CXXFLAGS, variable substitution works)
2. refer the package to that env file in /etc/portage/package.env (which is a file, not a directory)

In my case:

Code: Select all

# cat /etc/portage/env/znver3.conf 
CFLAGS="-O2 -march=znver3"
CXXFLAGS="${CFLAGS}"
# cat /etc/portage/package.env 
<kde-plasma/kwin-6 znver3.conf

... and after logging back in I can confirm that it really was due to an incompatibility in the CPU instruction set (and/or a GCC compiler bug?)

[Chiitoo]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260

[sam_]

Really, I'd say it's the KDE bugs https://bugs.kde.org/show_bug.cgi?id=469426 and https://bugs.kde.org/show_bug.cgi?id=460572.

The GCC bug you filed could easily be a mix of different things and some testcase would ideally be had. I haven't yet hit it myself but I do now have more AVX512 HW...

[Chiitoo]

Probably yeah.

I haven't actually tried with kwin:6 yet, to see if I still need to disable it.

Will try later today.

Edit:

From a quick emerge and 'kwin_x11 --replace &' looks like not needed any longer hmmm.

I'm also using GCC 14 already, though not sure if relevant.

[c00l.wave]

I'm also using GCC 14 already, though not sure if relevant.

I'm on GCC 13 and kwin 5, it's still an issue in that combination.

Really doesn't instill a lot of confidence in the other binaries GCC produced during world recompilation, who knows what else might have undetected errors in calculations or code branches right now... Could be safer to recompile everything with znver3 until it's clear if it's just causing "unimportant" anomalies in a few applications or maybe even affects packages related to storage etc.?

[sam_]

I'm also using GCC 14 already, though not sure if relevant.

I'm on GCC 13 and kwin 5, it's still an issue in that combination.

Really doesn't instill a lot of confidence in the other binaries GCC produced during world recompilation, who knows what else might have undetected errors in calculations or code branches right now... Could be safer to recompile everything with znver3 until it's clear if it's just causing "unimportant" anomalies in a few applications or maybe even affects packages related to storage etc.?

I've seen 0 testsuite issues so far and I tend to check these things quite heavily, but that's no guarantee of course. But it could easily be UB in kwin rather than a compiler bug.