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