Created attachment 152921 [details] Screenshot showing behaviour SUMMARY When I let a window snap into place along the screen sides, the contents are assumed to be about 5 pixels to the right. STEPS TO REPRODUCE 1. Drag a window that is re-sizeable and let it snap to the left side. 2. Resize the window once on the right side. 2. Attempt to resize the window again with the right side. OBSERVED RESULT Nothing happens. EXPECTED RESULT The horizontal resize cursor should display in the correct area. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo KDE Plasma Version: 5.26.0 on X11 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.5 ADDITIONAL INFORMATION If I move the mouse slightly to the right about 5 pixels, I can see the resize cursor and resize. All of the contents of the window are affected, not just the sides. The mouse coordinates become off by about 5 px, perhaps vertically as well in some cases but I have not yet seen that. As soon as I move the window away from being snapped, everything works as normal. This bug only affects snapped windows.
Cannot reproduce on Wayland with current git master.
Recently updated and I am still getting the bug. Two demonstration videos: https://youtu.be/Qup9ifJSCnc https://youtu.be/vwKTbOtpEkI Note where the mouse cursor is vs the window edges after the window is snapped.
Cannot reproduce with Chromium (in either CSD or SSD mode). Do you have any 3rd-party KWin scripts or effects active?
(In reply to Nate Graham from comment #3) > Cannot reproduce with Chromium (in either CSD or SSD mode). > > Do you have any 3rd-party KWin scripts or effects active? No KWin scripts enabled. Effects: Accessibility: Zoom Appearance: Background contrast Desaturate Unresponsive Applications Fading Popups Full Screen Login Logout Maximise Morphing popups Screen Edge Sliding popups Squash Show Desktop Animation: Window Aperture Virtual Desktop Switching Animation: Fade Desktop Window Management: Overview Present Windows Window Open/Close Animation: Scale
I made a new profile to test against just to make sure it's not a configuration issue. I was able to reproduce the issue in X11 as with my current profile. I was not able to reproduce the issue in Wayland.
Any thoughts on where I can look to possilbly fix the bug? Kwin source?
What if you toggle compositing? Does the window "fix" itself?
(In reply to Vlad Zahorodnii from comment #7) > What if you toggle compositing? Does the window "fix" itself? Yes. The window moves to the right a few pixels, to the correct position.
Can you run kwin with env QT_LOGGING_RULES="kwin*.debug=true" envvar and attach kwin's output to this bug report please?
Adding to my previous comment: This does not fully fix the window. It fixes Chrome it seems (somewhat), but everything else still thinks it's wider than it is after snapping to the left even without compositing. With Chrome, the issue is the shadow during compositing. When snapped to the left, the left shadow is gone so the handle on the right for resizing is off to right by 27px. This used to work in the past. With compositing off, Chrome forces the window to have a black border where the shadow would've been. So the resize handle goes to the correct place (at edge of browser window, not the shadow/border). The only commit I saw that looked interesting was one regarding Kwin switching to all floating point for metrics. But it is not easy for me to test a reversion of that change in its current state.
Created attachment 155349 [details] Kwin debug log kwin_core: Failed to create window pixmap for window 0x100000a (mismatched geometry) These lines mostly came when resizing Chrome on the right side while it was snapped to the left side of the screen, with compositing enabled.
The bug seems to be that the theme shadow is being used to figure out where to have the right-side (E) resize grabber trigger instead of the window edge. This seems to only happen when snapping the window to the left side of the screen (W snap). 1. Set Window Decoration to Breeze 2. In the Breeze theme settings (pencil icon), go to Shadows and set Size to Very Large and Strength to 100%. 3. Set 'Window border size' to 'No Borders' or 'Theme's default (No Borders)'. 4. For a KDE or Qt app window not snapped to the left side, note where the E resize grabber shows. 5. Drag that window to the left and let it snap. 6. Now note where the E resize grabber shows. The way I might have confirmed this is by setting the shadow strength to 100% and 'Very Large' (Breeze theme). Then I was able to clearly see where the grabber shows. The issue is 'fixed' for KDE/Qt windows by setting Window border size to Normal or bigger, but the theme's default is 'No Borders' and I'd prefer to have that. The setting change does not fix Gtk+ apps or Chrome. Worst for all of these is that the content is virtually about 30px to the right so interacting with the window does not work as expected at all. After unsnapping, the window goes fully back to normal.
> These lines mostly came when resizing Chrome on the right side while it was snapped to the left side of the screen, with compositing enabled. Do you see them after you've finished resizing chrome?
(In reply to Vlad Zahorodnii from comment #13) > > These lines mostly came when resizing Chrome on the right side while it was snapped to the left side of the screen, with compositing enabled. > > Do you see them after you've finished resizing chrome? These lines appear in the log immediately after finishing the resize of Chrome (on mouse button up).
I am not positive the lines are relevant to this bug because they appear after resize when the window is not snapped to the left edge of the screen.
It seems only *some* Gtk+ apps get affected. I was able to reproduce the same issue with dconf-editor but not Filezilla or GIMP. It seems some windows may have a particular way of drawing that triggers the bug?
Worst offender is Chrome. I cannot reliably trigger this issue with Dolphin, pavucontrol, etc. When compositing is enabled, after snapping Chrome wants to use the shadow of the window instead of the real edge of the window. The shadow should be ignored in that scenario. Chrome renders shadow on its own (or just black border with compositing disabled). This has nothing to do with the KDE theme shadow setting. It is not affected by my current Chrome settings. Chrome run with configuration reset has the same issue. A new user account exhibits the same issue. Let me know if there is more information I can provide. Settings -> Window Decorations: Theme: Breeze Window border size: Tiny
Can you check whether the issue is reproducible in 5.27?
.
(In reply to Vlad Zahorodnii from comment #18) > Can you check whether the issue is reproducible in 5.27? Still happening in 5.27. I rebooted after fully updating my system to ensure there are no conflicting old still running libs. Only non-maximised windows snapped to the left side of the screen are affected. This happens for others but most notably Chrome and Telegram.
I tried to reproduce this in the developer version of KDE Neon in VirtualBox and was not able to, even after matching up my settings as much as possible. I also tried building without -ftree-vectorize but this did not fix it either.
Built Kwin from source (tag v5.27.0) and ran with --replace. The issue does not appear in that build. The Gentoo build environment must be to blame.
This bug is actually caused by using --march=native to GCC. Maybe it's specific to my CPU or how my GCC is built. Regardless, it would seem the code path in question is sensitive to CPU optimisations. I can compile a local Git clone with -march=native and get the same behaviour. When -march=native is gone, the problem is gone. Can the section of code dealing with this be marked to avoid optimisation?
This is the moment where you provide upstream with more information about your toolchain and optimisation flags.
(In reply to Andreas Sturmlechner from comment #24) > This is the moment where you provide upstream with more information about > your toolchain and optimisation flags. More details: # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/12/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-12.2.1_p20230121-r1/work/gcc-12-20230121/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/12 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/12/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/12/include/g++-v12 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/12/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 12.2.1_p20230121-r1 p10' --with-gcc-major-version-only --enable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --enable-lto --without-isl --enable-default-pie --enable-default-ssp --with-build-config=bootstrap-lto Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.1 20230121 (Gentoo Hardened 12.2.1_p20230121-r1 p10) Building with -march=x86-64-v4 is what makes this break. -fsanitize=undefined gives the following on startup: $ kwin_x11 --replace /var/tmp/portage/kde-plasma/kwin-5.27.1/work/kwin-5.27.1/src/main_x11.cpp:113:46: runtime error: member call on address 0x7faff8006310 which does not point to an object of type 'KWinSelectionOwner' 0x7faff8006310: note: object has invalid vptr 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 25 00 00 00 ^~~~~~~~~~~~~~~~~~~~~~~ invalid vptr OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 OpenGL version string: 3.1.0 NVIDIA 525.89.02 OpenGL shading language version string: 1.40 NVIDIA via Cg compiler Driver: NVIDIA Driver version: 525.89.2 GPU class: Unknown OpenGL version: 3.1 GLSL version: 1.40 X server version: 1.21.1 Linux kernel version: 6.2 Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no Kwin runs and triggering the behaviour does not make further output. -fsanitize=address gives the following and Kwin aborts: $ kwin_x11 --replace ================================================================= ==20622==ERROR: AddressSanitizer: odr-violation (0x7fc35434f780): [1] size=48 'staticMetaObject' /var/tmp/portage/kde-plasma/kwin-5.27.1/work/kwin-5.27.1_build/src/kwin_autogen/7HEHEGDA3T/moc_common.cpp:119:38 [2] size=48 'staticMetaObject' /var/tmp/portage/kde-plasma/kwin-5.27.1/work/kwin-5.27.1_build/src/libkwineffects/kwineffects_autogen/include/moc_kwinglobals.cpp:108:38 These globals were registered at these points: [1]: #0 0x7fc35463a628 in __asan_register_globals /var/tmp/portage/sys-devel/gcc-12.2.1_p20230121-r1/work/gcc-12-20230121/libsanitizer/asan/asan_globals.cpp:341 #1 0x7fc354d8ec0d in call_init /var/tmp/portage/sys-libs/glibc-2.36-r7/work/glibc-2.36/elf/dl-init.c:70 #2 0x7fc354d8ec0d in call_init /var/tmp/portage/sys-libs/glibc-2.36-r7/work/glibc-2.36/elf/dl-init.c:26 [2]: #0 0x7fc35463a628 in __asan_register_globals /var/tmp/portage/sys-devel/gcc-12.2.1_p20230121-r1/work/gcc-12-20230121/libsanitizer/asan/asan_globals.cpp:341 #1 0x7fc354d8ec0d in call_init /var/tmp/portage/sys-libs/glibc-2.36-r7/work/glibc-2.36/elf/dl-init.c:70 #2 0x7fc354d8ec0d in call_init /var/tmp/portage/sys-libs/glibc-2.36-r7/work/glibc-2.36/elf/dl-init.c:26 ==20622==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0 SUMMARY: AddressSanitizer: odr-violation: global 'staticMetaObject' at /var/tmp/portage/kde-plasma/kwin-5.27.1/work/kwin-5.27.1_build/src/kwin_autogen/7HEHEGDA3T/moc_common.cpp:119:38 ==20622==ABORTING
The UBSAN/ASAN output is probably not related. -fno-tree-vectorize does not resolve the issue with -march=native (or x86-64-v4) which is suprising. For the last test these were the flags: CXXFLAGS="-O2 -ggdb -march=native -mtune=native -pipe -fno-tree-vectorize -fsanitize=undefined" LDFLAGS="-Wl,-O1 -Wl,--as-needed -fsanitize=undefined" Expanded native: CXXFLAGS="-O2 -ggdb -march=rocketlake -mabm --param=l1-cache-line-size=64 --param=l1-cache-size=48 --param=l2-cache-size=16384 -pipe -fno-tree-vectorize -fsanitize=undefined" LDFLAGS="-Wl,-O1 -Wl,--as-needed -fsanitize=undefined" rocketlake can be replaced with x86-64-v4 and the results will be the same.
To emphasise: - -O2 -march=x86-64-v3 works - -O2 -march=x86-64-v4 (or -march=rocketlake) triggers it
I tried every single -mno-avx512* option until I had all of them set. When all were set the issue was gone. So really, *any* AVX512 feature in use will cause this bug. I also tried with Clang and got the same results with all sorts of flag combinations.