My install of KDE is from about 5.6 or so.
After installing 5.8, the behaviour you can see in the linked video began. Any time a window on my left screen is grabbed by the titlebar, it jumps straight down to the bottom. When enough of the window is sitting on my right screen, it jumps back onto my cursor as normal. Using the Move command from the right click menu gives the same result.
I can use the window snapping features (dragging to top and side of screen) normally on both monitors. Even though the window jumps to the bottom of the screen, when my mouse hits the side of the monitor during the drag, it jumps into the correct position.
I can resize on the left screen normally.
I have tried turning off wobbly windows, no change. I'm using the NVIDIA proprietary driver on X.
Support Information: https://paste.kde.org/pel3hg45s
My Nvidia-settings window for my left (problematic) monitor: http://i.imgur.com/7WPdKCB.png
Steps to Reproduce:
1. Have two monitors
2. Drag a window on the left one
Window jumps down to the bottom of the screen. About 2-3 pixels of the window remain onscreen, but I can't grab that, only resize.
Window stays on the mouse cursor.
KWin Support Information:
The following information should be used when requesting support on e.g. http://forum.kde.org.
It provides information about the currently running instance, which options are used,
what OpenGL driver and which effects are running.
Please post the information provided underneath this introductory text to a paste bin service
like http://paste.kde.org instead of pasting into support threads.
KWin version: 5.8.1
Qt Version: 5.7.0
Qt compile version: 5.7.0
XCB compile version: 1.12
Operation Mode: X11 only
Vendor: The X.Org Foundation
Vendor Release: 11804000
Protocol Version/Revision: 11/0
SHAPE: yes; Version: 0x11
RANDR: yes; Version: 0x14
DAMAGE: yes; Version: 0x11
Composite: yes; Version: 0x4
RENDER: yes; Version: 0xb
XFIXES: yes; Version: 0x50
SYNC: yes; Version: 0x31
GLX: yes; Version: 0x0
decorationButtonsLeft: 0, 2
decorationButtonsRight: 6, 3, 4, 5
font: Noto Sans,10,-1,5,50,0,0,0,0,0
Active screen follows mouse: no
Number of Screens: 2
Refresh Rate: 60
Refresh Rate: 60
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 970/PCIe/SSE2
OpenGL version string: 3.1.0 NVIDIA 370.28
OpenGL platform interface: GLX
OpenGL shading language version string: 1.40 NVIDIA via Cg compiler
Driver version: 370.28
GPU class: Unknown
OpenGL version: 3.1
GLSL version: 1.40
X server version: 1.18.4
Linux kernel version: 4.7.7
Direct rendering: Requires strict binding: no
GLSL shaders: yes
Texture NPOT support: yes
Virtual Machine: no
OpenGL 2 Shaders are used
Painting blocks for vertical retrace: no
Currently Active Effects:
can you try removing the panel between your screens?
Whoa, that fixed it! Crazy stuff. Readding the panel causes the problem to reappear.
Thanks for testing! Now we know where the problem is.
*** Bug 372553 has been marked as a duplicate of this bug. ***
*** Bug 372796 has been marked as a duplicate of this bug. ***
Do You have a fix/patch to test? would be glad to test;
(As I understand this is related to recent changes in kwin
(i.e. August 2016: https://blog.martin-graesslin.com/blog/2016/08/panels-on-shared-screen-edges/)
In addition to what was already described, I want to add that this behaviour occurs on all four screen edges if there is a panel next to another screen/monitor.
As a workaround, I found that dragging a window while pressing the ALT key allows for normal movement.
*** Bug 374790 has been marked as a duplicate of this bug. ***
*** Bug 376088 has been marked as a duplicate of this bug. ***
What is necessary to make bug confirmed, assigned, and corrected?
Or is is this bug tracker merely a "please keep quit" place?
Is it useful to report bugs, or is it just a diversion?
> What is necessary to make bug confirmed, assigned, and corrected?
Confirmed has no meaning on KDE's bug tracker. In KWin we do not use assigned.
I hope to find time for this bug, but I cannot promise anything. In general nagging results in bugs getting way lower priority. Currently we have bugs of higher priority.
I confirm this bug. However for me it happens only when primary monitor has vertical panel. My video showing reproducing of this: https://yadi.sk/i/NeByvNm038yuxm
Are there any ideas what causes this behavior? It is quite easy to reproduce this, maybe bug status should be changed to CONFIRMED?
(In reply to paul_arts from comment #13)
> Are there any ideas what causes this behavior? It is quite easy to reproduce
> this, maybe bug status should be changed to CONFIRMED?
Sorry, I did not notice previous Martin Gräßlin's comment about confirmed status and bug priority. Anyway, please note that this bug makes KDE unusable on 2 widescreen monitors.
From my observation it does not happen when the window uses client side decoration. I tested it with Chromium with and without client-side decoration. When the Breeze decoration is enabled I experience the bug as reported. But when it's off I don't experience the issue anymore. So I tested it with Lollypop (GTK+ music player) and I can drag it without any problems as well.
I switched to cinnamon because of this bug. However, there, this bug seems to manifest itself by dropdowns (like menues) of kde apps not working in one screen (primary left for me), but working in the other.
*** Bug 379851 has been marked as a duplicate of this bug. ***
I'm affected by the bug too.
I want to also add that this makes yakuake unusable on the second monitor.
That is, when Yakuake is configured to pop-up on whichever monitor the mouse is, it will NOT pop-up if the mouse is on the second monitor.
I know multi-monitor setups are probably not that common, but this is a very bad bug for anyone wishing to use KDE in such a setup, and it gives out the message that KDE is badly broken.
Not many people will reach this bug-report before dumping KDE for another DE. And there's a good chance they will dump it anyway, even if this bug is rated as "not very important".
(In reply to Cristiano Guadagnino from comment #18)
> I'm affected by the bug too.
> I want to also add that this makes yakuake unusable on the second monitor.
> That is, when Yakuake is configured to pop-up on whichever monitor the mouse
> is, it will NOT pop-up if the mouse is on the second monitor.
> I know multi-monitor setups are probably not that common, but this is a very
> bad bug for anyone wishing to use KDE in such a setup, and it gives out the
> message that KDE is badly broken.
> Not many people will reach this bug-report before dumping KDE for another
> DE. And there's a good chance they will dump it anyway, even if this bug is
> rated as "not very important".
I agree as I am in exactly the same position.
I've always liked the look and functionality of Plasma but never given it enough time to make the switch, so I thought I'd make some time. An hour into setting things up I came across this bug and spent some time researching and troubleshooting, finally coming across this page. As this was reported 7 months ago and still not confirmed, I don't hold out much hope of things changing soon and unfortunately KDE is unusable (for me at least) without this being fixed. So i'm afraid I'm back off to another DE.
I'll keep an eye on this and perhaps I'll look at having another go with KDE once it's fixed.
*** Bug 380052 has been marked as a duplicate of this bug. ***
AFAIUI the problematic code is in AbstractClient::handleMoveResize (geometry.cpp) of kwin. As described in the blog post mentioned above, putting a panel in the middle of the screen covers the entire left screen internally. The code in AbstractClient doesn't seem to handle this: the entire left screen is removed from the "available" area for moving, which causes issues down the line.
For example, with my setup (1280x1024 left-of 1680x1050), a panel on the left-hand side of the right monitor has a "strut" of (0,0 1330x1049). Removing this area from the available area will cause issues. Setting the left edge of the strut to 1280 (the width of the left monitor) seemed to fix the issue for me but probably isn't a solution if this scenario is essentially not covered by the spec.
Pressing "Alt" while moving triggers an unrestricted move mode that just uses the entire (virtual) screen for moving and ignores the panel altogether, thus avoiding the issue.
*** Bug 381217 has been marked as a duplicate of this bug. ***
Daniel, thanks for your investigation. Based on that I did quite some additional investigation. I noticed that it is not trivial to fix. Everything I tried so far did not solve the problem properly and I think a larger refactoring of the code is needed. The "root" problem is that struts are constructed from the edge of the overall screen layout. So the strut of a panel in between restricts on all screens.
This code was so problematic that the Wayland implementation never got implemented and only has a TODO. Which explains why I couldn't reproduce this issue on Wayland. But on the other hand we also need to make it work on Wayland. Given that a larger refactoring is required. Luckily it's well contained and given the investigation so far it is possible.
But due to the fact that I think it will require a larger refactoring I doubt that this can be provided as a bug fix.
Possible patch at https://phabricator.kde.org/D6562
thanks for the patch! This does seem to solve the issue for me.
Git commit 14c8440f11f9af48e63ca0fcf05ee7988f445b9a by Martin Flöser.
Committed on 11/07/2017 at 15:51.
Pushed by graesslin into branch 'master'.
Restrict move resize area only on the screen the strut window is on
By allowing panels between screens in 5.8 to have a strut we created a
"regression" in KWin. KWin always was wrong, just we didn't notice as
neither Plasma nor previously Kicker set a strut on panels between shared
The strut is created from the edge of the overall screen setup. This
means a panel on the left edge of a screen on the right has the strut
starting from the left screen. KWin uses the strut to restrict the move
resize area: a window decoration is not allowed to go below a strut. Thus
it becomes impossible to move the window from the right to the left
This change tries to solve this problem by only restricting the move area
on the screen the window with the strut is on. E.g. if the window is on
the right screen, the left screen is not affected. Thus it's possible
again to move a window from one screen to the other as the added test
Unfortunately there are still corner cases where this won't work
correctly. If the window is on both screens this won't work. It is also a
rather heavy change for KWin and thus it's targeted for master and not
for the 5.10 or the 5.8 branch. If we notice that the patch works well
and doesn't create further issues, it should be considered for
Related: bug 370510
Test Plan: Added test case
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Differential Revision: https://phabricator.kde.org/D6562
M +151 -19 autotests/integration/struts_test.cpp
M +4 -0 geometry.cpp
*** Bug 377728 has been marked as a duplicate of this bug. ***
*** Bug 373689 has been marked as a duplicate of this bug. ***
*** Bug 384825 has been marked as a duplicate of this bug. ***
*** Bug 370583 has been marked as a duplicate of this bug. ***
*** Bug 384952 has been marked as a duplicate of this bug. ***
Hours ago I received an update to openSUSE Tumbleweed, so that now I'm on plasma 5.11.
I can confirm that (at last!) the bug is fixed and I can move windows on the second monitor without problems.
However the problem with Yakuake still remains: when configured so that its window appears on the monitor where the mouse cursor resides, it turns out that it really won't appear on the left monitor. That is: if I press the hotkey that is supposed to show Yakuake's window, it will do nothing if the mouse cursor is on the left screen.
This makes me think that the bug is still not completely solved.
I can confirm that Yakuake's behavior (i.e. it does not appear on the left monitor) is a direct consequence of this bug, because if I move my panel to the right side of the right monitor (instead of being "between the monitors"), Yakuake behaves correctly.
I tried to file a bug for Yakuake too, to see if it is possible to implement a workaround in Yakuake's code, but it actually makes more sense to fix the problem here.
I do not understand why this bug was reopened. The issue described in this bug report is fixed. Please do not just reopen bugs for other issues
Martin, how can you say the issue is solved if there's a program that shows the same behavior with the exact same cause?
The only difference here is that Yakuake cannot be dragged from one monitor to the other, due to the way Yakuake is shown on the screen, but it remains a fact that when Yakuake tries to appear on the second screen it's position is not what it should be resulting in an invisible window.
I am refraining from reopening the bug, for now. Should I open a new bug for this? It seems weird and counterproductive to me, because the main cause of the buggy behavior is the same so reading it in context would give a jump-start to anyone trying to fix the bug.
*** Bug 402160 has been marked as a duplicate of this bug. ***