Bug 404837 - Having monitors arranged vertically breaks "Move to next/prev screen" shortcut as well as yakuake
Summary: Having monitors arranged vertically breaks "Move to next/prev screen" shortcu...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.14.5
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Vlad Zahorodnii
URL: https://phabricator.kde.org/D20987
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-26 10:23 UTC by spam
Modified: 2019-05-15 08:07 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:
vlad.zahorodnii: ReviewRequest+


Attachments
Dualhead layout (6.68 KB, image/png)
2019-02-26 10:23 UTC, spam
Details
Support Information (5.96 KB, text/plain)
2019-05-07 09:42 UTC, spam
Details
Behavior of "Move to previous screen" in over/under layout (678.89 KB, image/png)
2019-05-07 09:52 UTC, spam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description spam 2019-02-26 10:23:35 UTC
Created attachment 118376 [details]
Dualhead layout

SUMMARY
Arranging screens with identical width vertically breaks "Move window to next screen" (and previous one too), probably everything related to screen switching.

Also Yakuake cannot be opened on upper (non primary) screen, and selecting different screen in it changes nothing, it always opens on lower one if you have selected specific screen instead of "follow cursor" 

STEPS TO REPRODUCE
1. Arrange screens as in attachment
2. Try using "move window to next screen" shortcut several times

OBSERVED RESULT
Window may move once but afterwards window plays short animation but stays on same screen

EXPECTED RESULT
Window cycles between screens

SOFTWARE/OS VERSIONS
Windows: no
MacOS: no
Linux/KDE Plasma: Debian Testing, Linux Kernel 4.19.0-2
(available in About System)
KDE Plasma Version: 5.14.5
KDE Frameworks Version: 5.54
Qt Version: 5.11.3

ADDITIONAL INFORMATION
Switching to horizontal layout fixes the problem but it's inconvenient since monitors are physically positioned that way.
Comment 1 spam 2019-04-01 09:46:28 UTC
Update: move to next screen is partially bugged because of krohnkite kwin script. However when script is disabled "move window to next screen" moves window either partially above the upper screen or right in between the screens
Comment 2 Vlad Zahorodnii 2019-05-07 08:32:12 UTC
Can you post output of `qdbus org.kde.KWin /KWin supportInformation` as well screenshots if possible?
Comment 3 spam 2019-05-07 09:42:43 UTC
Created attachment 119881 [details]
Support Information
Comment 4 spam 2019-05-07 09:52:40 UTC
Created attachment 119882 [details]
Behavior of "Move to previous screen" in over/under layout
Comment 5 spam 2019-05-07 10:02:09 UTC
I've added support information dump as an image showcasing how "Move to previous screen" is bugged. I've disabled krohnkite for better clarity. Note that window position after moving varies depending on it's initial position, feels like some offsets are horribly wrong. Sometimes window can go partially above upper screen but I couldn't reproduce it more than one and I didn't capture it. I've resized screenshots somewhat to save space, let me know if it's a problem.

Also as I mentioned before, this is one of several problems related to such layout. For instance yakuake is set to appear on same screen the cursor is, but it doesn't show up when cursor is on upper screen at all, setting specific screen in yakuake makes it always appear on lower screen, no matter which screen is selected.

Krohnkite also sometimes crashes kwin_x11 when external display is disconnected, probably related to wrong screen data, too.

All problems are gone if I use side-by-side monitor setup. During this time I changed external monitor for a bigger one but problems persist.
Comment 6 Vlad Zahorodnii 2019-05-07 10:31:34 UTC
Is the panel always visible?
Comment 7 Vlad Zahorodnii 2019-05-07 11:14:43 UTC
Can you reproduce this bug with the panel being hidden?
Comment 8 spam 2019-05-07 12:17:25 UTC
I made panel on lower screen "auto-hide" (it still stays always visible for some reason) and problem seem to be gone. Panel on upper screen doesn't change anything (but it does auto-hide properly).

I assume problem lies in "something lies beyond panel" case?
Comment 9 Vlad Zahorodnii 2019-05-07 12:19:56 UTC
Will look into it.
Comment 10 Vlad Zahorodnii 2019-05-08 09:14:38 UTC
Okay, this is a well known issue with struts. The fix is already under review.
Comment 11 Vlad Zahorodnii 2019-05-15 08:07:23 UTC
Git commit 67b2746ecdfd4c343db9d3fca088ae86d80a57f0 by Vlad Zagorodniy.
Committed on 15/05/2019 at 08:07.
Pushed by vladz into branch 'master'.

Compute correct boundaries in checkWorkspacePosition

Summary:
When a client sets a strut, checkWorkspacePosition will be called to
bump clients that touch corresponding screen edge.

In order to do that, checkWorkspacePosition needs to calculate client
boundaries before and after the restricted move area was changed. As it
turns out, if the client reserves space "between" screens, calculated
boundaries can be incorrect, which may lead to some funky results, e.g.
shrunken clients.

For example, let's say that there is a dual-monitor setup. If a client
reserves some amount of space at the right border of the left screen,
then clients on the right monitor will have rightMax which is equal to
the x coordinate of screenArea.

To fix that, this change ensures that only restricted areas belonging
to the same screen as the client are taken into account when computing
the boundaries.
Related: bug 406573

Reviewers: #kwin, davidedmundson

Reviewed By: #kwin, davidedmundson

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D20987

M  +4    -9    geometry.cpp

https://commits.kde.org/kwin/67b2746ecdfd4c343db9d3fca088ae86d80a57f0