plasma5 screen management going wrong

[Duncan]

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.  Google suggests there's not a lot 
of info out there about configuring plasma on wayland yet (a prominent 
hit is actually the arch wiki), but what I can find suggests that unlike 
X, there's no real desktop-independent configuration for wayland yet.  At 
some point I'm going to decide it's time to try (plasma on) wayland, and 
I've been kind of dreading it in part (one thing on a list...) because 
I've had such bad experiences with kde's X-based monitor configuration, 
while for better or for worse, that seems to be what I'll have to use.

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".  One 
can hope, anyway...

But I definitely expect kscreen/libkscreen will be needed to properly 
configure kwin_wayland and plasmashell on wayland, since that's the way 
that kde/plasma does it these days, and as I said, it appears there's no 
desktop-independent way to do it, so if my desktop is plasma on wayland, 
it'll have to be kde/plasma configuring it, and thus kscreen/libkscreen.

>>  And if I /do/ want to change the layout or resolution on-the-fly, I
>>  can use xrandr to do it, or simply
>> change the xorg.conf configuration and restart x/kde/plasma to have it
>> take effect.
> 
> It would be really helpful to find some examples of exactly how to apply
> your approach to a laptop which docks and undocks to/from a dock with
> multiple external displays. I would like to try your approach, but I
> don't have any experience with xrandr at all, and it has been an
> incredibly long time since I messed with xorg.conf. Any instructions or
> links are appreciated.

Wow.  While xorg does generally have sane no-xorg.conf behavior these 
days, I have a customized enough setup that I'd hardly consider doing 
without it, entirely!

Without actually checking, I'd (figuratively) bet money, however, that 
the arch wiki is one of the better resources out there on it.  Well, that 
and the xorg.conf manpage...

If you've not messed with xorg.conf in awhile, the biggest change you may 
not be aware of is that it's modular these days, configurable with 
multiple drop-in files (some of which are shipped by various xorg drivers 
in ordered to set defaults such as libinput (newer) or evdev (a bit 
older) as the default keyboard and mouse driver), instead of a single 
monolithic xorg.conf.  That makes it much *MUCH* easier to tweak just one 
thing, with a comparatively small configuration file likely with just one 
section and a couple configuration lines in it, either to override a 
shipped driver default, or to, for instance, configure one monitor 
"primary", with a second positioned "left-of" the primary.

As an example of why/how my config is somewhat customized, consider ($$ 
indicating a command, jed being my initials, my way of distinguishing my 
own settings files from the shipped defaults, this is for a radeon with 
the freedomware amdgpu driver, but the config should be similar for most 
freedomware drivers, if you're running nvidia with the servantware driver 
it may be different in which case you'll need to look elsewhere for that):

$$ cat /etc/X11/xorg.conf.d/jed.monitors.conf
# 48-inch 1080p youtube monitor
Section "Monitor"
	Identifier      "jed.mon.dvi0"
	Gamma           1.1
	Option          "Position"              "0 2100"
EndSection
################################################################################
# 65-inch 4K working monitor
Section "Monitor"
	Identifier      "jed.mon.hdmi0"
	Gamma           1.1
	Option          "Position"              "1920 0"
	Option          "Primary"
	Option          "PreferredMode"         "3840x2160"
EndSection

$$ cat /etc/X11/xorg.conf.d/jed.dev.conf
Section "Device"
	Identifier      "jed.dev.radeon"
	Driver          "amdgpu"
	Option          "Monitor-DVI-D-0"       "jed.mon.dvi0"
	Option          "Monitor-HDMI-A-0"      "jed.mon.hdmi0"
#	Option          "Monitor-DisplayPort-0" "jed.mon.dport0"
	Option          "TearFree"
EndSection


If you calculate those positions and sizes on a standard grid, you'll 
note that the my 1080p is /almost/ directly diagonally below and to the 
left of the primary 4k monitor, with the 1080p raised a few pixels from 
direct diagonal in ordered to provide a narrow path between them for the 
mouse (visual works best with monospace fonts and no autowrapping, just 
eyeballed, not to scale):

             +------------------------+
             |                        |
             |                        |
             |           4k           |
             |                        |
+------------+                        |
|            +------------------------+
|   1080p    |
+------------+


The idea is that I can play for instance youtube (either browser or 
minitube) full-screen in the 1080p monitor, while keeping the 4k free for 
me to do whatever (like reading and replying to list posts =:^) on the 
big one.  My default browser, konsole, etc, windows, are set to 
1280x1080, so two will fit overlapped on the 1080p monitor, or six will 
fit tiled three across by two down on the 4k, with no overlap.  Six 
working windows worth of space on the 65-inch/165cm 4k is plenty for my 
normal work (including a ksysguard window real-time graphing core, 
memory, temp, fan, and network metrics), leaving the 48-inch/122cm 1080p 
free for that full-monitor video window. =:^)

But the two obviously aren't the same dpi or resolution in either 
direction so I can't really treat them as a single unified monitor, and I 
use the monitor sides to constrain my pointer movement, so while they're 
physically side-by-side I don't want them logically side-by-side, as that 
wouldn't constrain the mouse movement to the one monitor on the boundary, 
so I position them logically almost diagonal, with just the small space 
for the mouse to move between them at the lower-left corner of the 
primary 4k.

But that isn't a common or natural setup, so I have to customize it, and 
as I said, I've found it easier to put a couple files in xorg.conf.d to 
do it and not let kde/plasma mess with it, than to try to set it up the 
way I want, and /keep/ it setup that way as I upgrade kde, in kde/plasma.

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.  
On gentoo it's part of the generic bash-completion package, which I have 
merged.  So here I simply had to do xrandr <tab> --o<tab> ... to get much 
of the commandline filled in or the choices displayed for me.   Since 
xrandr without parameters lists current outputs along with mode and 
position, and possible modes, and I already had the positions set that I 
wanted, I actually just used the xrandr output to get the positions to 
fill in, and the tab-completion gave me pretty much everything else.  I 
did actually run the command to make sure it worked, and it kept 
everything just as it was, without an error returned, which was what I 
intended, so it worked. =:^)

>> The trouble in this case seems to be that kscreen assumes a laptop with
>> a monitor attached...
> 
> Thanks for the clue. Knowing that this is related dto kscreen, I
> reported a bug here:
> 
> 396071 – plasma5 screen management going wrong
> https://bugs.kde.org/show_bug.cgi?id=396071
> 
>> There's no real way to tell it "hey, this is an xorg-preconfigured
>> desktop system, use it as-is and don't bother it".
> 
> It worked fairly well for the last two years. I agree with you that it
> has never been perfect or totally robust, but it was good enough not to
> interfere with our work in a major way until it became broken in the
> last couple weeks. Now it is a serious problem.
> 
> I need some help with further testing. In particular, could someone tell
> me which configuration files are involved in the System Settings
>> "Display and Monitor" settings? In particular, where does KDE store
> the screen geometry and relative placement (and primary display)?

That's kscreen, so I can't test it, and I have my locations customized 
via XDG_* vars, so I can't give you the defaults and be absolutely sure 
they're correct, but AFAIK the normal locations would be ~/.config/
kscreenrc (or similar) and ~/.local/share/kscreen/*.

And as it happens I have some old kscreen files in (my custom location 
corresponding to) the second one of those, the ~/.local/share/kscreen 
location, so that's probably it.

> And which config files are involved in the desktop background and panel
> placement for each screen?

Try ~/.config/plasma-org.kde.plasma.dkesktop-applesrc

Note that this file, while /nominally/ *.ini format, is definitely 
designed for machine parsing, not human text editing.  Basically, 
sections are organized by container ID and then applet/plasmoid ID, with 
each panel and screen-activity being its own container, and each plasmoid 
within that container having its own ID and one or more sections, but you 
have to figure out which one you're actually looking at based on the 
configuration.

For the desktops, the easiest thing I've found to tell them apart, 
assuming you have different wallpaper settings on each, is to find that 
setting.  Then you know which container you're dealing with and 
everything with the same container ID should be a setting for that 
desktop or something in it.

The panels don't have wallpaper but you can tell them apart from the 
desktops by their plugin type (org.kde.panel), and then if you have more 
than one, check the plasmoids in them.

Unfortunately, old panels/desktops/plasmoids don't always get entirely 
deleted, so if you've done a lot of customizing you may find a lot of old 
cruft in there confusing things.

But it's possible to hand edit it if you are patient enough...  Of course 
as always save a backup before you start screwing with things in case you 
make a mistake, and you can always return to defaults by just deleting 
the entire thing, tho if you customize as heavily as I do, having to 
start over from defaults isn't a very pleasant prospect.

> These are the main settings that are getting lost.

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