<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 18, 2016 at 2:06 PM, Fredy Neeser <span dir="ltr"><<a href="mailto:nfd@zurich.ibm.com" target="_blank">nfd@zurich.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p><tt>"Plasma-devel" <<a href="mailto:plasma-devel-bounces@kde.org" target="_blank">plasma-devel-bounces@kde.org</a>> wrote on 18.10.2016 13:11:29:<br><br>> From: Marco Martin <<a href="mailto:notmart@gmail.com" target="_blank">notmart@gmail.com</a>></tt><br><tt>> To: <a href="mailto:plasma-devel@kde.org" target="_blank">plasma-devel@kde.org</a></tt><br><tt>> Date: 18.10.2016 13:11</tt><br><tt>> Subject: Re: Breakout: * multiscreen behaviour: how should Plasma <br>> exactly behave in different scenarios?</tt><br><tt>> Sent by: "Plasma-devel" <<a href="mailto:plasma-devel-bounces@kde.org" target="_blank">plasma-devel-bounces@kde.org</a>></tt><span class=""><br><tt>> <br>> On Tuesday 18 October 2016, David Edmundson wrote:<br>> > <br>> > With regards to current Plasma behaviour that's not always true: I didn't<br>> > mention if screen 2 was previously the primary screen or not.<br>> > <br>> > At which point the correct behaviour should be to show the containers that<br>> > were previously on screen 2 on screen 1. Right?<br>> <br>> yes, that's the one case where the views get swapped to the other screen<br>> in ShellCorona::<wbr>primaryOutputChanged()<br></tt><br><br></span><tt>Hi all</tt><br><br><tt>I've been using KDE since about 15 years and I'm interested a lot</tt><br><tt>in the recent multiscreen improvements and the present discussion.</tt><br><tt>There is quite some complexity in changing multiscreen configs,</tt><br><tt>and I liked Marco Martin's summary of how Containments</tt><br><tt>(Desktop Containments or Panels) are linked to Screens etc.</tt><br><br><tt>Already with <= 2 screens (say, LVDS and one external screen scr1)</tt><br><tt>we can have 4 configurations (with * indicating the Primary Display),</tt><br><tt>namely</tt><br><br><tt>  c1 = [*lvds]</tt><br><tt>  c2 = [*lvds][scr1]</tt><br><tt>  c3 = [lvds][*scr1]</tt><br><tt>  c4 = [*scr1]</tt><br><br><tt>Based on the previous discussion, it seems that a Desktop Containment</tt><br><tt>D is configurable on a per-config and per-screen basis, so we have</tt><br><br><tt>  D = D(c,s)</tt><br><br><tt>where c is a config in {c1,c2,c3,c4} and s is a screen in {lvds,scr1}.</tt><br><tt>Moreover, a Panel P is apparently configurable on a per-config, per-screen</tt><br><tt>and per-resolution basis, so we have</tt><br><br><tt>  P = P(c,s,r,n)</tt><br><br><tt>where c and s are as above, r is a resolution, and n would be a panel index</tt><br><tt>(as there can be multiple panels per screen).</tt><br><br><tt>Using the above definitions and assumptions, we can ask a couple</tt><br><tt>of questions:</tt><br><br><tt>Q1. Among the possible transitions </tt><br><tt>       -    , c1 -> c2, c1 -> c3, c1 -> c4</tt><br><tt>    c2 -> c1,    -    , c2 -> c3, c2 -> c4</tt><br><tt>    c3 -> c1, c3 -> c2,    -    , c3 -> c4</tt><br><tt>    c4 -> c1, c4 -> c2, c4 -> c3,    -</tt><br><br><tt>from initial to final config, which ones are actually implemented</tt><br><tt>as atomic transactions in kscreen control?  -- I'm asking because</tt><br><tt>for example the transition  c1 -> c3 could be implemented</tt><br><tt>atomically as</tt><br><tt>    [*lvds] -> [lvds][*scr1]</tt><br><br><tt>or in two steps as</tt><br><tt>    [*lvds]       -> [*lvds][scr1]</tt><br><tt>    [*lvds][scr1] -> [lvds][*scr1]</tt><br><tt>with possibly different outcomes.</tt><br><br></p></div></blockquote><div>In general plasma shell never sees it as atomic. The underlying code in QPlatform window will emit two signals. Plasma then sees and processes it as two events.<br><br></div><div>But there's an added twist not mentioned. You can shutdown the computer in the middle of any one of those transitions. That then is effectively an atomic change, but also handled by a very different code path.<br><br></div><div>In terms of what currently Plasma does then:<br><br></div><div>Plasmashell then acheives the same thing but via a different code path; the outputsname to output Id orders gets swapped round in the ScreenPool constructor. Meaning that when we restore "0" may refer to lvds instead of scr1.<br><br></div><div>However, there's a subtle behavioural difference. With a running primary screen change we swap the new primary with the old primary ID. With a non running screen change, we set the new primary to 0, and the old primary becomes the first availableId.<br></div><div><br>With two outputs that will be the same, with n > 2, I'm not entirely convinced.<br><br></div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p><br><tt>Q2. Marco stated that containments never migrate from one screen</tt><br><tt>to another except when there is a "change of the primary screen".</tt><br><tt>But which config changes actually qualify as "change of the primary screen"?</tt><br><tt>I'd say</tt><br><tt>    [*lvds][scr1] -> [lvds][*scr1]</tt><br><tt>is such a change, but how about</tt><br><tt>    [*lvds] -> [lvds][*scr1]</tt><br><tt>?</tt><br><br></p></div></blockquote><div>That would be two events:<br></div><div>screen added:<br></div><div>primary screen changed<br><br></div><div>in that order<br></div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p><br><tt>Q3.  If I understand correctly, a "change of the primary screen"</tt><br><tt>causes ShellCorona::<wbr>primaryOutputChanged() to swap containments</tt><br><tt>between the old primary screen and the new primary screen,</tt><br><tt>so is it true that a config change</tt><br><br><tt>  c1 = [*lvds][scr1] -> c3 = [lvds][*scr1]</tt><br><br><tt>will always result in the swap operations</tt><br><tt>  D(c3,scr1)     := D(c1,lvds)</tt><br><tt>  P(c3,scr1,r,n) := P(c1,lvds,r,n)</tt><br><tt>  D(c3,lvds)     := D(c1,scr1)</tt><br><tt>  P(c3,lvds,r,n) := P(c1,scr1,r,n)</tt><br><br><tt>regardless of whether c3 is created for the first time</tt><br><tt>or recreated some time later?</tt></p></div></blockquote><br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p><br><tt>Q4.  For another example, if we consider the direct (atomic) transition</tt><br><tt>  c1 = [*lvds] -> c3 = [lvds][*scr1]</tt><br><tt>is this also handled by ShellCorona::<wbr>primaryOutputChanged() ?</tt><br><tt>Does it cause any containments to be migrated to another screen?</tt><br><tt>(If not, one might end up with c3 having no panel</tt><br><tt> the first time it gets created).</tt><br></p></div></blockquote><br></div><div class="gmail_quote">In the current code the panel that was on lvds will end up on scr1.<br></div><div class="gmail_quote">and lvds will have a 'new' containment on it.<br><br><br></div></div></div>