SUMMARY *** I'm using KDE Plasma (Arch Linux) on a Framework laptop - this has a 3:2 (2256x1504) aspect ratio. It works great in general, but I'm having trouble with quick tiling. Invoking a quick tile to the left or right of the screen isn't immediately reflected on the screen. Instead, you have to press another key before the window actually tiles. This user appears to have the same issue: https://www.reddit.com/r/kde/comments/zt9y7x/left_snap_seems_to_be_buggy_on_certain_screens/?sort=new This issue only occurs when trying to use fractional scaling - the behavior is not present at 100% or 200%. *** STEPS TO REPRODUCE 1. On a 3:2 (2256x1504) display, turn on fractional scaling (say, 130%). 2. Try to quick tile an application (Konsole, Dolphin) left or right a few times. OBSERVED RESULT Window does not always quick tile as expected. The window is logically tiled, but not visually tiled - meaning that KDE thinks the window is tiled, but is not displaying it in the correct position. Pressing any key afterwards seems to update the view, moving the window to the correct position. EXPECTED RESULT Window tiles left and right immediately. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux (Kernel 6.1.7-arch1-1) (available in About System) KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION - Appears to be a fractional scaling bug - https://www.reddit.com/r/kde/comments/zt9y7x/left_snap_seems_to_be_buggy_on_certain_screens/?sort=new Thank you!
I've been testing this myself and seeing the same behaviour. 100% scaling hasn't glitched for the few days i've been using it. 125% and i'd see the bug reported. It doesnt seem to matter what software is being snapped; native OS packages, additional software or flatpak - they all seem to experience the issue. Operating System: Fedora Linux 37 KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 6.1.7-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × 12th Gen Intel® Core™ i5-1240P Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® Graphics Manufacturer: Framework Product Name: Laptop (12th Gen Intel Core) System Version: A4
I confirmed the same behavior. Quick tiling works fine with integer scaling and is broken as described by OP when using fractional scaling (140% in my case). I reverted to forcing higher font DPI and 100% scaling.
I also experience the same behaviour. Specifically, my 2560x1600 (a 16:10 ratio) fails to switch correctly between left and right quick tiles when set to a fractional scaling of 165% or 170%, although most other fractional scaling ratios appear to work fine. Using 160% or 175% ratios is a functional workaround in my case. System information: Operating System: EndeavourOS (patched for use with T2 Macs) KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.6-arch1-Adashima-T2-1-t2 (64-bit) Graphics Platform: Wayland Graphics Processor: Mesa Intel® Iris® Plus Graphics
The original issue might be a duplicate of BUG 482687, which was fixed in 6.0.2. Would any of the original reporters be able to verify that? Thanks! (In reply to Philip Soerensen from comment #3) > I also experience the same behaviour. Specifically, my 2560x1600 (a 16:10 > ratio) fails to switch correctly between left and right quick tiles I don't think I understand what "fails to switch correctly between left and right quick tiles" means. Could you provide a screen recording and/or some more explanation? Thanks!
(In reply to fanzhuyifan from comment #4) > The original issue might be a duplicate of BUG 482687, which was fixed in > 6.0.2. Would any of the original reporters be able to verify that? Thanks! > > (In reply to Philip Soerensen from comment #3) > > I also experience the same behaviour. Specifically, my 2560x1600 (a 16:10 > > ratio) fails to switch correctly between left and right quick tiles > > I don't think I understand what "fails to switch correctly between left and > right quick tiles" means. Could you provide a screen recording and/or some > more explanation? Thanks! Sorry for the lack of details. I meant that my problem very closely replicates the behaviour of the original reporter. 1) Set the scaling ratio to 165% or 170% 2) Open any window, e.g. Dolphin 3) Quick tile to the left or right 4) Quick tile directly between left and right Expected behaviour: The window snaps immediately to the new position. Observed behaviour: The window initially doesn't respond (at least visually) to the quick tile command. The window appears to be stuck in the original location as long as it is left undisturbed. The window eventually moves to the expected location once it is disturbed by pressing a key or moving the cursor over the stuck window. I believe the action forces an update of the window, which then updates in the correct position. A few quirks: 1) The amount of "disturbance" a window requires before snapping into the expected place appears to depend on the application. Okular appears to work entirely as expected, Dolphin behaves as described above, and Firefox appears to be stuck in the wrong (old) location until it is unselected even if the window continues to be used. For Firefox, I need to selected another window before the location of the Firefox window updates and snaps into the expected location. 2) The problem only appears for very specific scaling ratios. 160% works fine, 165% and 170% are broken, and 175% works fine again. However, at 170%, Dolphin appears to have no problem going quick tiling from right to left, but fails in the manner described above when tiling from left to right. 3) The problem only appears when quick tiling directly between left and right. If I go through an intermediate state, such as quick tiling to top or untiling entirely in between the left/right quick tiled states, then there is no problem.
Created attachment 167880 [details] Screen recording of quick tiled window being stuck until distrubed Here is a screen recording of the strange behaviour. It might not be super useful since you can't see when I actually trigger the quick tile, but know that I trigger it before anything happens, and in the video you can see that the window doesn't move until I move my cursor over the window. Also, if I select another window after quick tiling, then the tiled window slides into the correct location behind the window now in focus. FYI: I tried disabling all my desktop effects without any results, so I don't think the problem is related to any effects. Thanks for looking into the issue!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
(In reply to fanzhuyifan from comment #4) Since posting the original bug, I've switched to Debian Sid. The issue still persists there at 150% on 5.27.10 - tiling Konsole left and right produces the same result as in the original post. Since I won't be getting Plasma 6 on Debian for a while, I ran KDE Neon from a live USB to test this. The scaling was automatically set to 150%. I was *unable* to reproduce the bug here (at least not with Konsole or Firefox).
I have updated the status to REPORTED since I still experience the problem on Plasma 6.0.3. Please let me know if there is any other information which you would find useful in addition to what I provided in comments #3, #5 and #6.
The problem appears to be fixed in Plasma 6.1.0. After the update, I am no longer able to reproduce the fault for any scaling ratio. I don't know which change resolved it, but at least on my system, everything now works smoothly, so I think we can move the bug to RESOLVED.
Great!