Bug 376843 - Maximizing a window on the 2nd screen throws the window to the primary screen and maximizes it there
Summary: Maximizing a window on the 2nd screen throws the window to the primary screen...
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.9.2
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 376973 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-02-23 12:50 UTC by Pekka Helenius
Modified: 2017-07-22 15:33 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pekka Helenius 2017-02-23 12:50:46 UTC
As described in the title, maximising a program window on the second screen throws the particular window to the primary screen and maximizes it there. Expected behavior is to maximize the window on the second screen since the window locates there.

This bug occurs when 

- you push maximize button on a window title bar or 
- click program icon (title bar) -> maximize
- double click a window title bar to maximize the window

I'm using Arch Linux with latest Plasma5/Qt5/Xorg/Nvidia packages available on Arch repositories. My OS is running on a laptop (Asus N56JR). The laptop uses Nvidia Optimus technology (Intel HD 4000 + Nvidia Geforce GTX 760M).

Primary screen resolution: 1920x1080 (oriented on the right side)
Secondary screen resolution: 1360x768 (oriented on the left side)

I've attached the second monitor with HDMI cable.

I don't have any Plasma5 panels on the second monitor, just a plain desktop with a background image. On the laptop screen I have just a basic desktop view with a bottom panel.

I recently upgraded from Plasma4/Qt4 to Plasma5/Qt5. This bug didn't exist on Plasma4 desktop.

I'm using X11 (not Wayland).
Comment 1 Martin Flöser 2017-02-23 15:49:07 UTC
Please provide the output of:
qdbus org.kde.KWin /KWin supportInformation
Comment 2 Martin Flöser 2017-02-27 15:51:13 UTC
*** Bug 376973 has been marked as a duplicate of this bug. ***
Comment 3 Pekka Helenius 2017-02-28 13:11:45 UTC
Thanks for commenting.

I can hardly provide any useful output by executing the command you suggested because...

Since I switched the left (smaller resolution) display to be my primary one, I haven't been able to reproduce the bug behavior. Not even if I change the right-side laptop display to be the primary one once again.

This bug still existed for me when

1) I did a clean upgrade from Plasma 4 to Plasma 5 (Arch Linux)

2) As the system suggested, kept the right-side laptop display as my primary one and the left-side external display as my secondary one (this was the setting I used in Plasma 4, too). 

The only thing system initially,right after the Plasma 4 -> 5 upgrade, incorrectly expected was that the external display was physically located at the right side of my laptop display whereas it located actually at the left side. I just flipped the display orientation in system settings but still kept the actual right-side laptop display as my primary one.

-----------------------

Worth mentioning:

The first time I flipped the orientation of the displays, I manually dragged them so that they accidentally overlapped each other. At the time, the bug was present. I noticed this overlapping issue so I re-oriented the displays to be seamlessly next to each other, using still same orientation. However, this had no effect to the bug.

-----------------------

3) Finally, crucial step was when I switched the left-side, smaller resolution external display to be my primary one. Since that I haven't been able to reproduce the bug anymore even if I change the laptop display to be the primary one again.

-------------------------------

Though I can't reproduce the bug, I think it still exists somewhere and the issue is still valid.
Comment 4 Martin Flöser 2017-07-22 15:33:33 UTC
It's possible that we fixed this bug with some changes in 5.11 or that it is another known issue. But we lack the information to properly identify, so I mark as waiting for info.