Bug 296673

is this really multihead? Multi-head means one X Server per screen which also requires to restart the X server after applying changes.

If that is not a multi-head setup I kindly ask you to close this report and create a new one not mentioning multi-head but mentioning exactly how you configure the two screens. This is extremely important to figure out whether this is correct behavior or if not where the bug is.

Certainly NOT multihead (behavior not possible) and actually the windows are NOT moved but remain on their position (because the reporter extends the screen layout on the northwest gravity) and are -if at all- corrected to remain in screen bounds.

So the request is actually to NOT preserve the window geometry but to DO move the window to a (the relative former) position on their old screen.

Right: removed multihead from title and tags.

And Right again: So the request is actually to NOT preserve the window geometry but to DO move the window to a (the relative former) position on their old screen.

IMHO it is wrong to preserve the window geometry (aka to have window A staying at coordinate (x,y) ), since when tiling screens the origin may change making (x,y) meaningless (it can even lead to windows falling across two screens). When /adding/ screens, I believe that one should always preserve the geometry relative to the older screen setup. When /removing/ screens, I think that one should change geometry to preserve the visibility of all windows.

Please, reconsider the wishlist status. To me this appears as a bug and one that can have unpleasant implications. This may expose private emails, passwords, material under NDA, etc to a wide audience when attaching a projector.

Indeed, people could close all their applications before starting a presentation or switch to a presentation activity, but this is not what you can expect them to do. This is similar to having a lock screen mechanism that does not hide the application windows. Surely, you can tell people to minimize their windows before locking, but can you expect them to do that?

The status is not some kind of degradation (while i agree that "wishlist" sounds a bit like "dear santa...")

You request a behavioral change for sth. that was maybe intended or just not considered, but is not caused by a false or clearly absent (TODO) implementation and afaik does not violate any followed specification.

This qualifies it as a feature request, what has NO impact whether it will be implemented or not, but -since it undoubted is a behavioral change- means that whatever happens cannot happen before 4.9. Tagging it as "whatever" would not change that, but only make it harder to identify.

While actually many user added "wishes" ultimately become -for various reasons- "wont fix", this one has been triaged to that status and is not out of scope and reasoned (just as btw. a similar wish for a window rule to control the screen as the virtual desktops) - otherwise it would likely have already become "wont fix".

*** Bug 317713 has been marked as a duplicate of this bug. ***

*** Bug 319183 has been marked as a duplicate of this bug. ***

*** Bug 324441 has been marked as a duplicate of this bug. ***

As far as my experience goes, this is a regression - I've had a setup for years with a desktop and a TV that's occasionally turned on (and configured to the left of the monitor). It always used to leave the desktop monitor and all windows on it untouched, and when the TV was turned on it would start off empty, and I'd move into it whatever window I wanted to see on it.

As of sometime in the past year (not sure when), this changed - now when the TV is turned on both screens go blank for a few seconds, and then they are both resotred, but with all my desktop windows moved into the tv (and a few stuck in between). The panel is the only thing that remains where it should be.

So this is a regression, and I'd really like to see the old behavior returned. Moving a user's windows around without him doing so explicitly is just a bad user experience.

I'm currently on Kubuntu 13.10, KDE 4.11.3, and NVidia 319.60 with TwinView. btw, if I have desktop effects enabled, when the TV is turned on both screen go blank and remain blank (other than the mouse pointer). I cannot enable desktop effects any more because of this (this also used to work with no issue until sometime in the past year).

(In reply to comment #9)
> As far as my experience goes, this is a regression
no. code didn't change. windows are not and were were *never* moved, the request is to change that.

your displays were likely aligned differently (Tv on right or bottom of monitor; ie. the monitor in the logic 0,0 position)

This has really nothing to do with your unspecific compositing issue.
For that, please open a bug report and attach the ouput of "qdbus org.kde.kwin /KWin supportInformation", "xrandr -q" and the file /var/log/Xorg.0.log - ideally when the dual screen is "black" and thus compositing active (delay the calls with "sleep" fot that purpose)

Mine might indeed be a regression in some other component - I don't know. For what it's worth, this happens with desktop effects disabled (due to a different issue I'm having with it), if that's what you meant by a compositing issue, and with my desktop (primary) monior being to the  right of the TV which is occasionally turned on, so the behavior seems to be that the window's absolute logical position remains the same (e.g. 0,0 for top-left corner), but is now applied relative to the leftmost display (TV) rather than the one it was originally on (the desktop monitor on the right). It didn't do that in the past - the setup was  identical but windows would remain at their position relative to the desktop monitor regardless of the TV on its left being on or off. Does it still sound unrelated? Should I open a separate bug?

(In reply to comment #11)
> Mine might indeed be a regression in some other component

Technically that's not a "regression"

As long as you ensure that the steady screen is on the top left position ("kcmshell4 kscreen", /etc/X11/xorg.conf*, some xrandr call in .xinitrc/.xprofile) it will not be moved by de/activating the other (and this is what happens in fact: the screen moves below the windows)

This is no way compositing related, but you started to side track a black screen issue, for which you shall please open a new bug with mentioned information (to keep this one "on topic")

Side note:
since i rencently moved my sidearm to the left and the behavior starts to annoy me, i'll look into a "fix" through a kwin script (as i assume the behavior can't change in the core during the KDE4 cycle)

> Technically that's not a "regression"
I meant a regression as in something that used to function properly (windows would not move around unexpectedly when turning on TV) and then stopped working (http://en.wikipedia.org/wiki/Software_regression). You mention that the KDE code behind this has never changed, so perhaps the regression is indeed in a different component - the NVidia drivers (TwinView), or X, or kscreen, or Kubuntu packaging... I honestly don't know. I just know it used to be ok, and now it ain't. If you have a hunch as to which component is responsible, I'll happily report the issue there. I apologize if I reported it in the wrong place - this bug report just sounded really similar, so I figured this might be it.

> As long as you ensure that the steady screen is on the top left position
> ("kcmshell4 kscreen", /etc/X11/xorg.conf*, some xrandr call in
> .xinitrc/.xprofile) it will not be moved by de/activating the other (and
> this is what happens in fact: the screen moves below the windows)
I'm pretty sure you're right - if I switch the monitors' left/right configuration it will probably work ok. Unfortunately, my primary steady screen is physically to the right of the TV, so configuring it to be logically on the left of the TV would provide bad user experience of a different kind. The proper solution imho would be for it to work the way it used to work for me in the past. Everything was perfect until the past few months.

> This is no way compositing related, but you started to side track a black
> screen issue, for which you shall please open a new bug with mentioned
> information (to keep this one "on topic")
This appears unrelated to me as well, I just mentioned it in case it might ring a bell to someone familiar with the inner workings of these mechanisms, seeing that both happen at the same time (when TV is turned on) and both never occured in the past and do now. I did report some of the (probably) unrelated issues with effects and black screens on launchpad for the NVidia drivers, since I was pointed at that as the probable culprit (though again, I'm not sure where the problem lies exactly).

Thanks!

Thanks Thomas for considering a script as a fix for this issue! I guess that your idea is to have the script react to a signal indicating a change in the screen configuration and then updating all the windows positions accordingly.  Is this correct?

Anyway, what I would like to recommend is to have the behaviour changed in kwin proper as soon as it is possible to do so, even if the script is made available.  Namely, I think it would be better to keep the script as a temporary fix only.  

In fact, IMHO, the current behavior is particularly wrong because it can easily reveal private information to a wide audience when a projector is attached.  Hence, a behavior that is safer and saner in this respect should IMHO become part of the /standard/ experience and not depend on having a specific script installed. I am also worried that the script approach may have some kind of delay, where the windows are first shown on the 'new' screen and then brought back to the 'former' one. If this is the case, the privacy implications would only be attenuated and not eliminated.

Let me remark that I really appreciate Thomas idea of a script and his effort.  Only for a not so near future I would like to assure that the sane behavior is a default experience.

http://kde-look.org/content/show.php?content=162304

No idea whether this can be changed for KDE4 since it's a behavioral change, we cannot add a config option and there will be for *sure* ppl. ranting about it.

I upgraded yesterday to Kubuntu 14.04 (with KDE 4.13.0, although I had that since before this upgrade, and with nvidia drivers 331.38-0ubuntu7, and whatever other components were upgraded in 14.04). Now the desktop effects are once again usable here (yay!), and when they're enabled the behavior is back to the way it used to be - when I turn on the TV (to the left of the monitor), the windows which are open on the monitor remain where they were and the TV has no windows on it. However I just tested it with desktop effects disabled, and the issue is still there (windows move to TV).

So personally the issue is no longer bothering me since I will be running with the effects enabled and get the desired behavior, but to whomever is investigating it - the behavior is different depending on the state of desktop effects. I hope this info helps.

What?
Do you use some 3rd party effect? Window effects are not supposed to have the least impact on this (and i don't see how they could, except blocking kwin some even cycles during which your setup alters through different states - though those  should be aggregated anyway)

What really *should* happen (not necessarily what you want, but what's there in the code) is that all windows remain on their global position - unless they'd drop out of sight.

Could you please provide the outputs of
- "xrandr -q" (before and after the screen-relayout)
- "xwininfo" (on a random window that would change it's position) before and after the screen-layout
for both (composited and uncomposited) cases?

Thanks

Created attachment 86310 [details]
xrandr and xwininfo logs

You're right, the facts were correct but the analysis wrong - I tried recreating it a few times and found inconsistent behavior, but it was not entirely related to the desktop effects (maybe that was only a coincidence), and I proceeded to test with effects always enabled.

It seems that some windows are affected and some aren't, and also some are returned to their original position after the TV is turned off and some not. In the attached logs, I got the info for xrandr -q and xwininfo on 3 windows: FireFox, Konsole and Konversation, all run in one command piped into the log file at each phase.

1 - after a fresh reboot of the system, only monitor is on
2 - after TV is turned on, the windows moved
3 - after TV is turned off, some windows moved back, but e.g. Konsole remained in its TV-on position and never returned to its original position

Then I moved Konsole manually back to the original position, and maximized FireFox. Note that I've seen the following behavior happen also when FireFox was taking up the full screen (give or take a few pixels) but wasn't officially maximized, i.e. the titlebar showed the maximize button and not the restore button. But after a reboot this was no longer the case, so I reproduced it with actually maximizing the window.

4 - FF maximized
5 - after TV is turned on, FF stays in place but other windows move
6 - after TV is turned off, FF stays in place, Konsole stays in place (as before), other windows moved.

These are the ones I captured in log, but as stated, even after a fresh reboot, TV on, TV off, reboot cycle, the behavior was not consistent (e.g. sometimes FF moved and sometimes not, when it was not officially maximized but visually appeared more or less so).

*** Bug 335063 has been marked as a duplicate of this bug. ***

Should be possible on QScreen::name() now.

*** Bug 344396 has been marked as a duplicate of this bug. ***

The current behavior is obviously wrong.
It may look technically cool to translate windows positions to the new resolution settings, but in the real life, it is a pure annoyance.

I give conference and training almost every day, and it is a real embarrassment that all windows from my main screen (laptop) may show on the projection screen : e-mail, private notes, etc.
It is always something I worry and do not trust on my system.

I tried to workaround this by using some kwin script, but the result is broken in other ways and not usable with a laptop.

No other major window environment made this choice : Gnome, Mac OS, Windows... There are some good reasons, don't you think so ?

Could you please consider this as a bug ? And a serious one, as it raises some security issues. Security is not solely about tricky super cool use-after-free or overflows, it is also about physical basic stuff...

(In reply to Jean-Christophe Baptiste from comment #22)
> It may look technically cool to translate windows positions to the new
> resolution settings

Windows are NOT translated and this is not about being "cool" but for a long time this would not even have been technically possible, because no information about the physical screen (the connection, not the logical number) was wired up (thus the majority of X11 WMs does -still- not act on randr events)

> No other major window environment made this choice : Gnome, Mac OS,
> Windows... There are some good reasons, don't you think so ?

KWin made no choice at all - it takes the workspace as single surface (as that is what it technically is and no other view on it was available for most of the time) that grows and shrinks for irrelevant causes (eg. because you changed the resolution)
Even in gnome you'll notice that the windows first briefly appear on their original position before they're translated with awareness of the physical screen.

To ensure this does not happen at all, just make sure your projector gets added on the right or bottom of your notebook screen (which implicitly preserves the NB screen geometry in global coordinates)

Please stop being so picky with the vocabulary. Call it as you want and give me all possible technical reason, I am not a dev and as a user, I don't care.
The important thing is that I think anyone is understanding what we, users, mean, about this annoying and insecure behavior.

Concerning your suggestion of placing the screen on the right side, you should rather have taken a few more seconds of thoughts. Your usage is not necessarily representative of all usages, and some people, like me, are using this feature intensively (not just for movie watching).

So, you mean that the external screen at my office cannot be placed anywhere else than on the right side ? Ridiculous : the user has to adjust to the bug.
And what if it is not physically possible due to my desk arrangement,  or I just prefer left ? Actually, in this place, I am placing it on the top, as recommended by ergonomic positions.

Last, but not least, when you give presentations as I do, you often move to many customer places. So you have no choice on the external screen position and you have to deal with it 8 hours a day, 5 days a week, in front of a booth. In these moments, I may have ten of windows opened : virtual machines, slides, notes, diagrams.... Are they all meant to be showed to the booth ? No. Am I supposed to resort all of them every time I come back with the laptop, or when the projector suspends after a break ? I hope, no.

As you say yourself, even if it is a dirty trick, at least Gnome seems to be aware of it and is trying to do it right.

In any way, whether technically or functionally,  it should be fixed.

I'm not picky, but you're re-stressing a misconception about the sublying problem
It's not that kwin simply would have to deactivate some stupid behavior. This requires quite some changes to the codebase and is a feature request, not a bugfix (KWin manages windows, not screens - not acting on screen changes is expectable plain behavior)

Ok, understood, even if I am always astonished by this classic answer : it is not a bug, it is a feature, fill a feature request instead.

But, well, there is something wrong, so now, what will happen. Is it taken into consideration or shall we open a new ticket as a feature request ? Will there be an action plan or is it going to stay like that for the next 10 years ?

Just to know if and how it can be improved, as my frustration is big with it (so sad, because KDE is perfect on almost every other points).

This /is/ an open feature request and comment #20 pointed out a meanwhile path to implement it.
My personal motivation didn't exactly raise during the last hour but it's still an open and just feature request and if someone (incl. Martin or myself) implements it, it will oc. be added.

Any implementation will however only happen in KWin/5 - KDE Workspace/4 is feature frozen (actually only security fixes in terms of pot. priv leverage are to be accepted)

That's cool ! Thank you for your time and your explanations, I will be waiting to see it in KDE 5.

Jean-Christophe Baptiste, thanks for repeating the explanation about the current behavior.

Yet, I believe that treating this as any other enhancement request would not be totally correct.
As some users have pointed out, the current behavior has some serious security implications. Whatever you may have on screen, including confidential or sensitive data, may suddendly (and unexpectedly for the users that do not know about this behavior) appear on a large projection screen.

The fact that the behavior has historically always been like this and that until a recent past there was not even sufficient infrastructure to deal with it does not change the fact that one has a wrong (buggy) behavior with security implications.  IMHO, if this cannot be fixed, at least the user should be alerted (namely, kscreen should never activate an external monitor to the left upper corner automatically without reporting to the user the risk of sensitive information appearing on the wrong surface and asking for a confirmation).

To draw a parallel, this would be like having the computer exposing sensitive data to the net when you plug a network cable unless the informed user takes some explicit precaution.


(regardless of the fact that it has been like that since the very first implementation, this is true for most buggy behaviours)

Please ignore last line in previous comment. It is a leftover from editing.

Thomas, please don’t be pi**ed. Just try to feel the pain of your users ;) It may be technically correct and proper for you, as you know the underlying technical details. For the user this is just weird, annoying, broken behaviour, which really can drive you crazy. Leave alone privacy issues. I for instance threw KDE from my laptop a year ago, and one important point was the (not)handling of external displays (not only KWins fault to be fair). And the information about screens and positions is there. Maybe not from X11 directly, but from xrandr, kscreen or whatever (which has this info for years, IIRC). And even if it’s not great technically, even if it flickers, it’s still a lot better than nothing. I’m sure you guys are clever enough to find a viable solution.

So if you say that it’s an open request for KWin5 the question really is which priority does it have? For many users things like that to "just work” are a ton more important than for instance any 3D, composition bling you guys put so much energy into. Yes I know, you do this for fun and in your sparetime and nobody can force you ;) But for KDE as a whole non-cool things like that are important to stay relevant.

on X11 the situation is not trivial - a window is not bound to an output. This makes any changes only guesses - we can be right, we can be wrong. We don't know whether you connect an external projector, we don't know what you are doing. Yes, it would be possible to implement heuristics, but I would consider it wrong as it can never be what users expect - and that's true for all environments on X11. It's a technical restriction, period.

The proper (short term) solution is to only expand to the right, so that no windows end up on that position automatically and that is exactly what KScreen does by default. One needs to *manually* configure to have it behave differently to e.g. expand to the left.

The long term solution is called Wayland: on Wayland windows can be easily connected to an output and also (IIRC) the window can know on which output it is. This makes it rather easy to ensure that windows don't go to a new output. Of course there will still be cases where this happens: if you disconnect a screen, the windows will move. No matter how sensitive the information is: inaccessable is worse.

Overall I don't think this will change in short term on X11 - at least I do not have any time for working on it.

(In reply to Martin Gräßlin from comment #32)
> on X11 the situation is not trivial - a window is not bound to an output.

Well, on a zaphod setup it is ;-)
For the xrandr case actually have a rule for this, but the rule applies to numbers, not names.
Ie. if screen 1 becomes 2 (because you added the primary screen), the (force) rule will "of course!" move the window to the other screen.
=> We could turn that into a name rule instead and be en par on all backends, but I'm not sure whether that would help here.

For the dynamic handling, the idea was to store the screen setup in an internal QMap<QString, QRect>, mapping the screens "name" ("vga-0", "dvi-i-1", etc.) to it's global geometry.
Then intercept screen count changes, update the map, compare the result to the previous map and adjust geometries (where was the client on the old map, where is that on the new map)


The problem is that this is indeed not trivial for especially the non-trivial n>2 case, because all kinds of conflicts can occur.

Eg. if you've screens "A | B" and inject a third screen "A | C | B", where do you put a window that previously was between A & B? ("Where the larger part was", "Where it occupied more relative space"?)
And should it be exposed on C?

Equally when removing screen C:
Should a windows that previously was between C and B now be exposed on A - or rather shrink to fit C? Move partially offscreen if it cannot be shrunk sufficiently?

The problems then grow w/ a 2D layout and screen numbers :-(

Assume the larger part™ of a window had been on the bottom screen that now became the top - the titlebar would be off-screen as a result (unless we forcefully constrain positions)

Assume you had a window on single screen A, but its topLeft() < (0,0) or bottomRight() > (wA,hA), and add a screen where the window was previously just in "dead" space.
=> The former dead part of the window is now visible on that screen...

> This makes any changes only guesses - we can be right, we can be wrong.
Wrt the above, I'd not guess at all and require configuration:
The user has to either declare outputs A, B and C parts of a video wall or declare output D a dynamic extra (not part of a wall, don't "keep" windows onto it)
On a layout change involving a dynamic screen, windows must be constrained to be on or off that (those) screens or the video wall (no intersection allowed) - even if that kills some positions when eg. "A | B" -> "B | A"

> on X11 the situation is not trivial - a window is not bound to an output. This makes any changes only guesses - we can be right, we can be wrong. We don't know whether you connect an external projector, we don't know what you are doing

Probably it is sufficiently easy to be right as long as the expectations are set to a sufficiently low level and defined through a policy that the user can be easily made aware of. Actually we just want to prevent exposing something to a newly attached screen because this poses at risk the sensitive data of the user. In fact, xrandr provides sufficient information about screen attach and detach events (kscreen already uses this information to switch on and off screens automatically).

I think that there are two ways of dealing with the situation when xrandr is present.

1) The 'geometric approach'
  - when a screen is added consider it as a potential change in the 'origin' of the virtual surface.
So, for all the screens, one records the current screen offset.
When a new screen is attached, for each screen before the attachment one can compute the offset delta and determine a list of the windows that had their origin in it before the attachment event. Hence, all these windows positions can be updted by the offset delta
 - when a screen is detached the inverse is done, but then an additional check is made to verify that the windows that were completely on the removed screen are moved to the primary screen (otherwise they would remain unmanageable). By moving on the primary screen, we move to the screen that acts as the user console.

(this can only make windows that strech across multiple screens appear on the newly attached screen and only if this is placed 'in the middle'. Which I regard as a non significant case.)

2) The 'minimal approach'
- when a new screen is added, all windows that would go (completely or partially) to that screen are moved to the primary screen
- when a new screen is removed, all windows that would completely disappear because of that are moved to the primary screen

(personally, I prefer 1).

In fact, I believe that some logic of this sort already exists.  For instance, if you add a screen to the right and to the top of the current screen (new screen gets vertical offset 0 and horizontal offset equal to the old screen width, old screen gets a non negligible positive vertical offset), windows stay on the old screen and do not move to the space not covered by any screen in the top left corner of the virtual surface. Hence, windows do not always preserve their position relative to the virtual surface already.

> The proper (short term) solution is to only expand to the right, so that no windows end up on that position automatically and that is exactly what KScreen does by default. One needs to *manually* configure to have it behave differently to e.g. expand to the left.

I do not think that this is the case, because of two reasons:

1) People need to add screen where this makes work comfortable and mouse movements to reach it intuitive.  If you have a projection screen, most likely it will be /above/ your screen, so you want to add it above and not below. And if the projection screen also happens to be on the left, you want to add it left, because it is anti-intuitive to move the mouse right to reach something on the left.
2) The first time you attach the screen, by default kscreen places it right, as noticed. However, if you want/need to move it to the left, the only safe thing to do right now is to /close/ all your windows before you do it. Otherwise when you move, all the windows will appear on the new screen  for all the time required to /manually/ move them elsewhere.
3) Once you have created a setup for your screens, kscreen remembers it and the next time it will put it automatically to whatever position you decided.
No, I do not think that

(In reply to Sergio from comment #34)

> Actually we just want to prevent exposing something to a newly attached screen because this poses at risk the sensitive data of the user.

Just don't use a porn wallpaper ;-)

Seriously: either this is done correctly (ie. we support dynamic screens) or we'll have the same stupid discussion when ppl. have increasing demand to manage multiple screens beyond the notebook+projector case.

What you describe could be tagged a different bug and be covered by a rule that re-applies "initially" on screen layout changes and enforces all windows to be ("initially") on screen 1 (this will also prevent you from accidentally opening a window on the connected projector first, but you'd have to move them there)

> By moving on the primary screen, we move to the screen that acts as the user console.
You're aware that the primary screen can be dynamic? (Ie. if the specified 1st screen is not connected, "some" other screen is the primary one until the primary one is connected)

I pointed out the required mechanisms in my last post, w/o that you can pretty much forget about control.

> In fact, I believe that some logic of this sort already exists. 
No.

> if you add a screen to the right and to the top of the current

The former root geometry ends up in dead space and a very general sanity check moves all windows inside a visible area.

> Just don't use a porn wallpaper ;-)

Would be great if the problem was just the porn wallpaper ;-) probably people would just laugh at it. The problems are consoles with a password, pdf viewers with documents under NDA,  emails from the boss, or sketches of a new product. These things can make you fired. And with 'virtual desktops' it is not that difficult to forget about some window around.

> You're aware that the primary screen can be dynamic? (Ie. if the specified 1st screen is not connected, "some" other screen is the primary one until the primary one is connected)

I know, but I really do not see it as so significant.
- With strategy 1) the 'primary screen' is used just to assure that everything remains in visible areas on detach. And a detach event is not so significant in terms of exposure of sensitive data.
- Even with strategy 2), after the first use, kscreen remembers which screen should be the primary one, so a setup already verified by the user is applied. 

Furthermore I think that it is correct to assume that the primary screen is safe, because this is where the user gets notifications anyway.

> The former root geometry ends up in dead space and a very general sanity check moves all windows inside a visible area.

Indeed. Which to me means that it is not true that windows always keep the same position wrt to the virtual surface origin. Already, when a new screen is attached/detached some logic is invoked that can alter the windows origins. What  I think should be feasible is enhancing this logic a little.

My strategy 1) keeps all the windows that are fully exposed on a view exactly in the same position on that view. Then, on detach, a sanity check is applied for windows that would end up on an dead space and these are moved to the primary screen.  Yes, there are 'corner' cases that the strategy does not cover very well (windows that stretch between multiple views). But they are much less significant than the 'middle of the room' case that goes wrong now and that regards /all people with a laptop who need to connect a projector/.  I may be wrong, but this appears to me as a larger number of users than those who have identical monitors side to side and use applications that stretch through them and then need to add a further monitor in the middle.

I was forgetting one bit:

> Seriously: either this is done correctly (ie. we support dynamic screens) or we'll have the same stupid discussion when ppl. have increasing demand to manage multiple screens beyond the notebook+projector case.

I think that by that time wayland will be ready and those users will be the first and most motivated to migrate to it. Yet, for years to come, there are going to be users stuck with X and still with a need to securely use a projector.

One more question...

Incidentally, will wayland solve the situation when one has X applications with a rootless X server running in wayland?

Script to cover the special situation where you do not want to expose your porn wallpaper to your audience =)

It constrains all windows to the primary screen whenever a screen is added.
This does NOT provide a general solution to the subjected bug, but be good enough.


http://kde-look.org/content/show.php?content=169388

Installation (on SC4)
plasmapkg -t kwinscript -i protectPornPrivacy.kwinscript

Thank you Thomas.
Even if I don't have a porn wallpaper, it helps :-)

This definitely helps. Can it be made a default component of the distribution?

----

A quick note to other who might want to test the script.  After installation it must be enabled.
This can be done via the kcm Script module that is in

System Settings -> Window Behavior -> Kwin Scripts

Thanks Thomas that helps a lot!

The only little problem is that when I plug in my external monitor the full-screen windows on my laptop screen apparently get resized to the full size of the laptop screen (1600x900) disregarding the bottom panel (task bar, ...). E.g. konsole tabs get hidden behind the task bar, so does status bar from LibreOffice, etc.

Is this something that can be fixed in the script?

(In reply to mludvig from comment #41)

> The only little problem is that when I plug in my external monitor the [...]
> size of the laptop screen (1600x900) disregarding the bottom panel (task

Is that a vertical screen layout? -> Bug #94470?
(In case, that's a defect in the spec - the panel doesn't tell KWin to keep windows away and that would be forbidden by the protocol)

(In reply to Sergio from comment #40)
> Can it be made a default component of the distribution?
By that very name? ;-P

SC4 is frozen (ie. your distro can ship whatever they want, but there won't be non-critical upstream changes)
KF5 should ideally see a fix to this bug resp. maybe (also) adjusted rules (re-applying enforcements on screen layout changes)
    => I'd say "at best if both is ruled out"
        (and even then: we actually have the scripting for especially side-channel distribution of custom features)

Hi, nope both screens are horizontal - external VGA1 @1920x1080 positioned above laptop's LVDS1 @1600x900.

Perfectly reproducible here - unplug VGA1, open a full screen Chrome - it doesn't cover the bottom task bar, plug in VGA1, both screens blink, Chrome stays on LVDS1 but bottom edge gets hidden behind the task bar.

> Hi, nope both screens are horizontal - external VGA1 @1920x1080 positioned
> above laptop's LVDS1 @1600x900.

Like so (in doubt, attach "xrandr -q" output)?

-----------------
|      VGA1   |
-----------------
--------------
|  LVDS1 |
--------------

That *is* a vertical layout, the pivot mode of a screen is irrelevant.
Panels on bottom of VGA1 or top of LVDS1 aren't strutting.

*** Bug 357837 has been marked as a duplicate of this bug. ***

*** Bug 369511 has been marked as a duplicate of this bug. ***

*** Bug 374498 has been marked as a duplicate of this bug. ***

Thank you very much for still keeping this open.

I have been used to configure my screens only to the right side of my laptop for 1-2 years now because of that exact problematic behaviour. It is somewhat sad that this will not come for x11.

I am surprised that this is a technically difficult problem to approach. The control bar is placed on the correct monitor and new windows also open on the correct screen. KScreen reflects the information of xrandr with the relative translation of the screen.

Each window has its top left corner distinctively in one of the screens. If that screen has a new position, the window moves with it. Even choosing the center point as a mapping to the output would not be that terribly wrong nor any 'strange heuristic' imho.

Ultimately this would be also only half the truth. While it would be good if KWin takes its windows along with the screens anyway, when connection a new screen it should not really require to move the old one. But that would require X11 to allow negative positions which I can understand might be more refactoring and work.

I am putting up high hopes in wayland… multiscreen-setups have been a PITA on KDE/linux for the last century while it was nailed pretty solidly on other OSs :S
I'll give Neon a spin and try it on my main system with plasma 5.9.

This problem can also be seen when using kscreen to change the relative position of windows:

1. Connect a new screen. KDE adds it to the right of the current screen. The new screen comes up with none of the currently open windows and no panel.
2. Use the "Displays" configuration to change the order, moving the new screen to the left of the current screen (actual world use case - my external monitor is on the left side of my laptop, because on the right side there's a door).

Expected behavior: All the windows currently open on the laptop screen stay on the laptop screen, the panel stays on the laptop screen and the new empty screen is just re-positioned logically so that moving the mouse outside the left border of the laptop screen will enter the new screen.

Actual behavior: the new screen gets logically ordered to the left side of the laptop screen, the panel stays on the laptop screen, but all the open windows move to the new screen leaving the laptop screen empty of windows.

While I understand the argument for considering this issue a wishlist, it does reflect an unexpected and surprising behavior to the user - and is also a different behavior than any other commonly used windowing system (e.g. GNOME, MacOS and Windows).

Still an annoying issue. For some reason, protectPornPrivacy.kwinscript does not always work (some windows would get to the external screen).

Is there any way to harden the script further?

New developments are talked about in:
Connecting new screens
https://vizzzion.org/blog/2018/02/connecting-new-screens/

New developments are talked about in:
Connecting new screens
https://vizzzion.org/blog/2018/02/connecting-new-screens/

*** Bug 412322 has been marked as a duplicate of this bug. ***

*** Bug 418548 has been marked as a duplicate of this bug. ***

*** Bug 415821 has been marked as a duplicate of this bug. ***

Git commit 4928f4db5b810969c70d549729c23ff95d1a6781 by Vlad Zahorodnii.
Committed on 30/10/2021 at 14:02.
Pushed by vladz into branch 'master'.

Try to preserve window position relative to their outputs during hotplug

Currently, if an output is hotplugged, all windows will be scrambled,
which is highly annoying.

With this change, windows will stick to their outputs if an output has
been connected or disconnected.
Related: bug 378896, bug 412703, bug 443698

M  +10   -12   src/abstract_client.cpp

https://invent.kde.org/plasma/kwin/commit/4928f4db5b810969c70d549729c23ff95d1a6781

>> With this change, windows will stick to their outputs if an output has
been connected or disconnected

So if I disconnect my external monitor (primary one, located to the right) with some windows opened on it, they won't automatically move to the laptop's screen (secondary one, located to the left)? Am I getting this right?

No, windows from the disconnected output will be transferred to another output that's still connected.

Oh nice, I'm glad I have misinterpreted this.