Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[David Edmundson]

On Tue, Oct 18, 2016 at 2:06 PM, Fredy Neeser <nfd at zurich.ibm.com> wrote:

> "Plasma-devel" <plasma-devel-bounces at kde.org> wrote on 18.10.2016
> 13:11:29:
>
> > From: Marco Martin <notmart at gmail.com>
> > To: plasma-devel at kde.org
> > Date: 18.10.2016 13:11
> > Subject: Re: Breakout: * multiscreen behaviour: how should Plasma
> > exactly behave in different scenarios?
> > Sent by: "Plasma-devel" <plasma-devel-bounces at kde.org>
> >
> > On Tuesday 18 October 2016, David Edmundson wrote:
> > >
> > > With regards to current Plasma behaviour that's not always true: I
> didn't
> > > mention if screen 2 was previously the primary screen or not.
> > >
> > > At which point the correct behaviour should be to show the containers
> that
> > > were previously on screen 2 on screen 1. Right?
> >
> > yes, that's the one case where the views get swapped to the other screen
> > in ShellCorona::primaryOutputChanged()
>
>
> Hi all
>
> I've been using KDE since about 15 years and I'm interested a lot
> in the recent multiscreen improvements and the present discussion.
> There is quite some complexity in changing multiscreen configs,
> and I liked Marco Martin's summary of how Containments
> (Desktop Containments or Panels) are linked to Screens etc.
>
> Already with <= 2 screens (say, LVDS and one external screen scr1)
> we can have 4 configurations (with * indicating the Primary Display),
> namely
>
>   c1 = [*lvds]
>   c2 = [*lvds][scr1]
>   c3 = [lvds][*scr1]
>   c4 = [*scr1]
>
> Based on the previous discussion, it seems that a Desktop Containment
> D is configurable on a per-config and per-screen basis, so we have
>
>   D = D(c,s)
>
> where c is a config in {c1,c2,c3,c4} and s is a screen in {lvds,scr1}.
> Moreover, a Panel P is apparently configurable on a per-config, per-screen
> and per-resolution basis, so we have
>
>   P = P(c,s,r,n)
>
> where c and s are as above, r is a resolution, and n would be a panel index
> (as there can be multiple panels per screen).
>
> Using the above definitions and assumptions, we can ask a couple
> of questions:
>
> Q1. Among the possible transitions
>        -    , c1 -> c2, c1 -> c3, c1 -> c4
>     c2 -> c1,    -    , c2 -> c3, c2 -> c4
>     c3 -> c1, c3 -> c2,    -    , c3 -> c4
>     c4 -> c1, c4 -> c2, c4 -> c3,    -
>
> from initial to final config, which ones are actually implemented
> as atomic transactions in kscreen control?  -- I'm asking because
> for example the transition  c1 -> c3 could be implemented
> atomically as
>     [*lvds] -> [lvds][*scr1]
>
> or in two steps as
>     [*lvds]       -> [*lvds][scr1]
>     [*lvds][scr1] -> [lvds][*scr1]
> with possibly different outcomes.
>
> 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.

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.

In terms of what currently Plasma does then:

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.

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.

With two outputs that will be the same, with n > 2, I'm not entirely
convinced.


> Q2. Marco stated that containments never migrate from one screen
> to another except when there is a "change of the primary screen".
> But which config changes actually qualify as "change of the primary
> screen"?
> I'd say
>     [*lvds][scr1] -> [lvds][*scr1]
> is such a change, but how about
>     [*lvds] -> [lvds][*scr1]
> ?
>
> That would be two events:
screen added:
primary screen changed

in that order

>
> Q3.  If I understand correctly, a "change of the primary screen"
> causes ShellCorona::primaryOutputChanged() to swap containments
> between the old primary screen and the new primary screen,
> so is it true that a config change
>
>   c1 = [*lvds][scr1] -> c3 = [lvds][*scr1]
>
> will always result in the swap operations
>   D(c3,scr1)     := D(c1,lvds)
>   P(c3,scr1,r,n) := P(c1,lvds,r,n)
>   D(c3,lvds)     := D(c1,scr1)
>   P(c3,lvds,r,n) := P(c1,scr1,r,n)
>
> regardless of whether c3 is created for the first time
> or recreated some time later?
>



>
> Q4.  For another example, if we consider the direct (atomic) transition
>   c1 = [*lvds] -> c3 = [lvds][*scr1]
> is this also handled by ShellCorona::primaryOutputChanged() ?
> Does it cause any containments to be migrated to another screen?
> (If not, one might end up with c3 having no panel
>  the first time it gets created).
>

In the current code the panel that was on lvds will end up on scr1.
and lvds will have a 'new' containment on it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20161018/43c4c5f4/attachment.html>