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