Bug 356074 - Windows should not open on inactive monitors
Summary: Windows should not open on inactive monitors
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2015-11-29 13:21 UTC by Reuben
Modified: 2018-10-27 04:21 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Reuben 2015-11-29 13:21:22 UTC
I have a laptop with a small screen, and a large external monitor that I plug in and use when at home. At home I close the laptop screen.

With this configuration, plasma opens all applications on the closed laptop screen, even though I dug through settings and selected "active screen follows mouse".

Ubuntu handles this correctly in their unity environment, so it should be entirely possible to implement in plasma. It should be a simple rule: new applications should not open in inactive monitors.

Even better, "active screen follows mouse" should be a) default and b) fixed so that it actually works reliably (which it is obviously not here.)
Comment 1 Thomas Lübking 2015-11-29 15:29:52 UTC
the setting works fine, but clients can demand specific positions (and that is honored by default, window rules allow you to override it)

-> does it actually fail for *all* new windows?
can you also please attach the output of "xrandr -q" for your problematic setup?

defaults are handled as bug #355513

in general it's not possible (for kwin) to know that you closed the lid (but that usually fires a signal that kscreen could use to remove the output)
Comment 2 Reuben 2015-11-29 15:38:34 UTC
Actually, correction - system settings was reliably opening on the large monitor after I selected this setting, but other windows (e.g. Chrome, IIRC Dolphin) were not.

Glad defaults is "confirmed", hope for that to be fixed.

xrandr:

$ xrandr -q
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
LVDS1 connected (normal left inverted right x axis y axis)
   1366x768      60.03 +
   1360x768      59.80    59.96  
   1280x720      60.00  
   1024x768      60.00  
   1024x576      60.00  
   960x540       60.00  
   800x600       60.32    56.25  
   864x486       60.00  
   640x480       59.94  
   720x405       60.00  
   680x384       60.00  
   640x360       60.00  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
   1920x1080     60.00*+  50.00    59.94  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.88  
   1400x1050     59.95  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x960      60.00  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.08    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x576i      50.00  
   720x480       60.00    59.94  
   720x480i      60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08  
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Comment 3 Thomas Lübking 2015-11-29 16:50:02 UTC
The randr ouput says the LVDS1 isn't active and the workspace is only the 1920x1080 if the HDMI monitor.

Unless we missed the config change, KWin won't position windows outside that workspace area and clients must try *really* hard to move there (ie. they must actually bypass the WM), chrome however restores its position ... (dolphin should not), so if the former position was outside 1920x1080, it might try to get there.

Can you also please attach the output of "qdbus org.kde.KWin /KWin supportInformation" (to confirm we didn't simply "miss" the re-layout) and check a bit whether this may actually rather be a chrome issue?
Comment 4 Martin Flöser 2016-08-29 11:10:28 UTC
Please provide the output of
qdbus org.kde.KWin /KWin supportInformation
when having the problem. Also xprop and xwininfo of a window opened on the inactive screen would be useful.
Comment 5 Andrew Crouthamel 2018-09-26 22:22:34 UTC
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 set the bug status 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!
Comment 6 Andrew Crouthamel 2018-10-27 04:21:16 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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

Thank you for helping us make KDE software even better for everyone!