View previous topic :: View next topic |
Author |
Message |
c00l.wave Apprentice
Joined: 24 Aug 2003 Posts: 268
|
Posted: Sun Jun 30, 2024 10:16 am Post subject: [SOLVED] KDE Plasma 5: Windows can not be moved off screen |
|
|
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? _________________ nohup nice -n -20 cp /dev/urandom /dev/null &
Last edited by c00l.wave on Sun Jun 30, 2024 2:12 pm; edited 1 time in total |
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 9259
|
|
Back to top |
|
|
c00l.wave Apprentice
Joined: 24 Aug 2003 Posts: 268
|
Posted: Sun Jun 30, 2024 1:33 pm Post subject: |
|
|
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/portage/package.env#Use_different_MAKEOPTS_for_a_specific_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: |
# 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?) _________________ nohup nice -n -20 cp /dev/urandom /dev/null & |
|
Back to top |
|
|
Chiitoo Administrator
Joined: 28 Feb 2010 Posts: 2726 Location: Here and Away Again
|
|
Back to top |
|
|
sam_ Developer
Joined: 14 Aug 2020 Posts: 1946
|
|
Back to top |
|
|
Chiitoo Administrator
Joined: 28 Feb 2010 Posts: 2726 Location: Here and Away Again
|
Posted: Sun Jun 30, 2024 3:23 pm Post subject: |
|
|
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. _________________ Kindest of regardses. |
|
Back to top |
|
|
c00l.wave Apprentice
Joined: 24 Aug 2003 Posts: 268
|
Posted: Sun Jun 30, 2024 4:49 pm Post subject: |
|
|
Chiitoo wrote: | 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.? _________________ nohup nice -n -20 cp /dev/urandom /dev/null & |
|
Back to top |
|
|
sam_ Developer
Joined: 14 Aug 2020 Posts: 1946
|
Posted: Sun Jun 30, 2024 5:24 pm Post subject: |
|
|
c00l.wave wrote: | Chiitoo wrote: | 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. |
|
Back to top |
|
|
|