plasma5 screen management going wrong

[Duncan]

Bug Reporter posted on Thu, 12 Jul 2018 19:06:02 -0400 as excerpted:

Snip, but I see you're making progress...

>> - 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.
> 
> This would appear to depend upon the names of the screens, such as
> "DP-2-1". My guess is that if the dock itself is the same model device,
> the display ports may be named the same by xrandr. Obviously, it is not
> hard to come up with the required command for additional office
> locations. However, it would be more convenient if a non-technical user
> (one who can barely use a terminal) had exactly one command to execute
> for docking, regardless of the office. But, in worst case, I can see
> making scripts or aliases such as "dock-east" and "dock-west". The
> undock script/alias would always be the same.

The names are the names of the outputs.  I'm not familiar enough with 
laptop docks to know about them, but for both desktop systems and stand-
alone laptops, the outputs are a property of the graphics adapter and 
thus don't normally change unless you switch out graphics cards.  Tho I 
suppose one dock might expose only say an HDMI, while another might 
expose a DVI-I, which allows both a digital (DVI-D) and an analog (DVI-A 
or via converter VGA) connector, with the graphics actually having both 
and the dock determining which one is actually exposed via plug.

Regardless, if you make the script complex enough it can parse say an 
xrandr output and see what's available, activating whatever it finds at 
the preferred resolution, thus making it connection-agnostic and even 
resolution-agnostic, as it simply uses the preferred resolution, whatever 
that happens to be on whatever's plugged in.

>> - 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?

Yes.  xrandr is the generic-X CLI/scripted way of managing things when X 
is running, with xorg.conf the way to manage things when you're starting 
X.  There are also various GUIs like kscreen to do what xrandr does but 
via GUI instead of CLI, but I've always had better luck with X's own 
tools, xrandr or xorg.conf.  Tho it seems you've had better luck than I 
with kscreen.  But as I wrote in an earlier reply, that may be because I 
tend to run less common layouts that kscreen likely isn't well tested 
with, so I run into corner-case bugs more often.

>> - 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?
> 
> After just a little testing, this seems like a robust solution.

Yes.  The generic X-based solutions tend to be quite robust.  If worse 
comes to worse and the display is screwed up so you can't read the output 
at all, you can blind-run something like xrandr --output HDMI-A-0 --auto, 
and as long as the EDIDs aren't entirely insane (and you know what output 
to use from previous use, of course), it should come up with at least a 
/usable/ display.

> However, the key to whether or not this will be practical for me is
> power management. Having to remove KDE's PowerDevil means I now have to
> go and explore alternative means of managing power on a laptop. Any
> suggestions?


You /might/ look into something like laptop-mode-tools.  I used that here 
on my netbook, when I had one.  If you've noticed, I tend to use generic 
non-desktop-specific tools, which tend to be more reliable for me, 
particularly over kde major version changes when the old version tools 
often aren't available any longer, while the new ones are still flat-out 
broken, at least for all but the developer-tested common cases. (Tho kde 
did far better in this regard with the 4.x -> 5.x upgrade than they did 
with the 3.x -> 4.x upgrade, which was a fiasco piled on breakage piled 
on another fiasco.)

Anyway, laptop-mode-tools is no exception, being a generic collection of 
tools that sort of grew up around a UI that originally just exposed the 
kernel's laptop-mode, but now including all sorts of modules that allow 
controlling all sorts of things, triggering at wall-plug-toggle, power 
events, laptop-lid events, etc.

But like xrandr, it gives you more control, is easier to script, and 
tends to be as or more reliable than the desktop-specific GUI tools, but 
it has a harder initial learning curve as it's not just point and click 
like the GUIs.

So as they say, YMMV...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman