plasma5 screen management going wrong

[Bug Reporter]

see below

On Thu, Jul 12, 2018 at 2:20 AM, Duncan <1i5t5.duncan at cox.net> wrote:
> Bug Reporter posted on Wed, 11 Jul 2018 21:05:22 -0400 as excerpted:
>
>> see below
>>
>> On Mon, Jul 2, 2018 at 2:25 AM, Duncan <1i5t5.duncan at cox.net> wrote:
>>> Bug Reporter posted on Sun, 01 Jul 2018 21:17:29 -0400 as excerpted:
>>
>>> This is likely the kscreen component, or libkscreen ...
>>>  I finally unmerged/uninstalled those two components
>>
>> To clarify, you removed kscreen and libkscreen? I'm running Arch Linux,
>> so I can probably uninstall those packages as well.
>
> Correct.  kscreen and libkscreen are not installed (on gentoo, aka
> "merged") here, despite the fact that I have kde-plasma as my desktop
> environment, with plasmashell providing the desktop and panels, and kwin
> as the window manager.
>
> It's possible there's something with a direct buildtime/runtime
> dependency on them, but it doesn't seem to be anything I have merged, or
> if it is, it's USE-flag controlled and I have that flag off.
>
> Actually... just did a grep on libkscreen in the (gentoo) repo, thus
> covering packages I don't have installed as well.  Other than kscreen
> itself, there's two other packages depending on it:
>
> powerdevil:  On gentoo at least, this appears to be a hard dep, buildtime
> and runtime.  The reason it doesn't affect me is that I don't have
> powerdevil installed either.
>
> Interestingly enough, the other one is lxqt-config.
>
> Nothing (well, other than the plasma-meta metapackage) appears to dep on
> kscreen itself.
>
> Meanwhile, note that I'm still on X.

Yes, I see it the same way. I will switch to Wayland once it has full
support under KDE and is reliable.

> It's possible, however, that the past problems have all been due to kde
> "fighting" with X over the configuration, and if there's no standard non-
> kde config to mess up, with some luck perhaps it'll all "just work".

My experience over most of the last two years is that it has "just
worked" -- until a couple weeks ago.

> Doing the same with xrandr, presumably scripting it to the settings you
> use frequently and then either running the script with selected
> parameters or running the appropriate script to change things, isn't
> difficult.  It'll just take some study of the xrandr manpage.  Typically
> you'd do something like this (for the same outputs/size/positioning as
> above):
>
> xrandr --output HDMI-A-0 --primary --mode 3840x2160 --pos 1920x0 --output
> DVI-D-0 --mode 1920x1080 --pos 0x2100
>
> Note that there's a bash-completion helper available for xrandr as well.

Can you say more about how this would work on a laptop that is docked
and undocked daily? Some questions include:

- Upon putting the laptop on the dock (multiple external monitors) can
I run my randr script (or command) to activate the dock-connected
monitors without logging out of plasma? The "without logging out" part
is important. If we have to log out and restart X, that's no better
than kscreen at the moment because if we restart after docking,
kscreen usually gets things right. (Until two weeks ago, it got things
right immediately when the dock was connected without any user
intervention at all.)

- Upon undocking, I assume I would run another randr script to disable
the external monitors, then I would undock the laptop.

- Say I have two different docking stations (one in the east coast
office one in the west coast office). Say both have the identical
monitor layout (e.g., two 1920x1080 HDMI monitors side by side). Will
the same randr dock-connect script work at the other office? The
monitors will have different EDID's, of course. But the relative
positions and the resolutions will be the same.

- With xorg conf files, I assume that switching from the undocked to
the docked configuration requires logging out of plasma, restarting X,
and logging back in. Correct?

- Are there frequent or common situations where one could lose all
monitor output and a non-sudo user would be required to restart the
computer?