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 Reproducible: Always Steps to Reproduce: 1. Have two monitors 2. Drag a window on the left one 3. why?! Actual Results: 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. Expected Results: 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. ========================== Version ======= 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 Build Options ============= KWIN_BUILD_DECORATIONS: yes KWIN_BUILD_TABBOX: yes KWIN_BUILD_ACTIVITIES: yes HAVE_INPUT: yes HAVE_DRM: yes HAVE_GBM: yes HAVE_X11_XCB: yes HAVE_EPOXY_GLX: yes HAVE_WAYLAND_EGL: yes X11 === 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 Decoration ========== Plugin: org.kde.breeze Theme: Blur: 0 onAllDesktopsAvailable: false alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 0, 2 decorationButtonsRight: 6, 3, 4, 5 borderSize: 3 gridUnit: 10 font: Noto Sans,10,-1,5,50,0,0,0,0,0 smallSpacing: 2 largeSpacing: 10 Options ======= focusPolicy: 0 nextFocusPrefersMouse: false clickRaise: true autoRaise: false autoRaiseInterval: 0 delayFocusInterval: 0 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false placement: 4 focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: true focusStealingPreventionLevel: 1 legacyFullscreenSupport: false operationTitlebarDblClick: 5000 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 30 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 30 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 31 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777251 showGeometryTip: true condensedTitle: false electricBorderMaximize: true electricBorderTiling: true electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true inactiveTabsSkipTaskbar: false autogroupSimilarWindows: false autogroupInForeground: true compositingMode: 1 useCompositing: true compositingInitialized: true hiddenPreviews: 2 glSmoothScale: 2 colorCorrected: false xrenderSmoothScale: false maxFpsInterval: 16666666 refreshRate: 0 vBlankTime: 6000000 glStrictBinding: false glStrictBindingFollowsDriver: true glCoreProfile: true glPreferBufferSwap: 0 glPlatformInterface: 1 windowsBlockCompositing: true Screen Edges ============ desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens ======= Multi-Head: no Active screen follows mouse: no Number of Screens: 2 Screen 0: --------- Name: DVI-I-0 Geometry: 0,0,1920x1080 Refresh Rate: 60 Screen 1: --------- Name: DVI-D-0 Geometry: 1920,0,1920x1080 Refresh Rate: 60 Compositing =========== 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: NVIDIA 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 Loaded Effects: --------------- zoom slidingpopups kwin4_effect_login wobblywindows slide screenshot kwin4_effect_windowaperture kwin4_effect_translucency minimizeanimation cube sheet resize kwin4_effect_morphingpopups kwin4_effect_maximize kwin4_effect_fade presentwindows highlightwindow kwin4_effect_dialogparent blur contrast windowgeometry startupfeedback screenedge kscreen Currently Active Effects: ------------------------- blur contrast Effect Settings: ---------------- zoom: zoomFactor: 1.2 mousePointer: 0 mouseTracking: 0 enableFocusTracking: false followFocus: true focusDelay: 350 moveFactor: 20 targetZoom: 1 slidingpopups: fadeInTime: 30 fadeOutTime: 50 kwin4_effect_login: wobblywindows: stiffness: 0.06 drag: 0.9 moveFactor: 0.1 xTesselation: 20 yTesselation: 20 minVelocity: 0 maxVelocity: 1000 stopVelocity: 0.5 minAcceleration: 0 maxAcceleration: 1000 stopAcceleration: 0.5 moveEffectEnabled: true openEffectEnabled: false closeEffectEnabled: false moveWobble: true resizeWobble: true slide: screenshot: kwin4_effect_windowaperture: kwin4_effect_translucency: minimizeanimation: cube: cubeOpacity: 0.800000011920929 opacityDesktopOnly: false displayDesktopName: true reflection: true rotationDuration: 100 backgroundColor: #000000 capColor: #31363b paintCaps: true closeOnMouseRelease: false zPosition: 100 useForTabBox: false invertKeys: false invertMouse: false capDeformationFactor: 0 useZOrdering: false texturedCaps: true sheet: duration: 100 resize: textureScale: true outline: false kwin4_effect_morphingpopups: kwin4_effect_maximize: kwin4_effect_fade: presentwindows: layoutMode: 0 showCaptions: true showIcons: true doNotCloseWindows: false ignoreMinimized: false accuracy: 20 fillGaps: true fadeDuration: 30 showPanel: false leftButtonWindow: 1 rightButtonWindow: 2 middleButtonWindow: 0 leftButtonDesktop: 2 middleButtonDesktop: 0 rightButtonDesktop: 0 highlightwindow: kwin4_effect_dialogparent: blur: blurRadius: 12 cacheTexture: true contrast: windowgeometry: handlesMoves: true handlesResizes: true startupfeedback: type: 1 screenedge: kscreen:
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
Hi Martin, 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 Summary: 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 screen edges. 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 screen. 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 case shows. 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 backporting. Related: bug 370510 FIXED-IN: 5.11 Test Plan: Added test case Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D6562 M +151 -19 autotests/integration/struts_test.cpp M +4 -0 geometry.cpp https://commits.kde.org/kwin/14c8440f11f9af48e63ca0fcf05ee7988f445b9a
*** 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. ***