Re: plasma5 screen management going wrong
Bug Reporter posted on Fri, 13 Jul 2018 18:52:16 -0400 as excerpted: > However, I do not want to remove powerdevil, therefore, I cannot remove > kscreen. I looked at laptop-mode-tools and I did not like what I saw. It > looks very dated. I'm not confident it will work that well on modern > hardware. For example, I'm running NVMe drives. I don't want to get > diverted from the task at hand by having to solve a bunch of power > management issues, so powerdevil has to stay installed -- but I want to > disable kscreen. > > In addition to KSC_XRandR11.so, which me mentioned previously, I see > KSC_Fake.so, and that prompts a question. > > # ls /usr/lib/qt/plugins/kf5/kscreen/ > total 504 > drwxr-xr-x 1 root root136 Jun 27 12:50 . > drwxr-xr-x 1 root root490 Jun 20 21:45 .. > -rwxr-xr-x 1 root root 100176 Jun 26 09:15 KSC_Fake.so > -rwxr-xr-x 1 root root 104360 Jun 26 09:15 KSC_KWayland.so > -rwxr-xr-x 1 root root 67408 Jun 26 09:15 KSC_QScreen.so > -rwxr-xr-x 1 root root 75600 Jun 26 09:15 KSC_XRandR11.so > -rwxr-xr-x 1 root root 157608 Jun 26 09:15 KSC_XRandR.so > > What would happen if I copy KSC_XRandR11.so to KSC_XRandR11.so.bak and > then copy KSC_Fake.so to KSC_XRandR11.so? I wonder if that would render > kscreen "disabled" while leaving it installed. Any thoughts on this? That's a very creative idea! =:^) I hadn't noticed the fake one, but my guess is that it's there to provide a "fake" backend for CI/constant-integration testing, on a build/testing server (well, probably a VM/container these days) that very well may not have a real X/wayland session available to play with. The fake backend would allow testing without such a session, or without messing up an existing session if it were available. It's also possible it could be used for installations on other OSs, OSX and some of the other BSDs, and perhaps even MS Windows, where there might not be a direct tie-in to the native power and screen management. Of course switching it out may not work, and if it does it'll very likely disable the powerdevil display management, that of course being why powerdevil would depend on it in the first place. That may or may not be OK with you. The only way to see is to try, but I'm guessing you're already doing just that. =:^) -- 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
Re: plasma5 screen management going wrong
see below On Fri, Jul 13, 2018 at 2:35 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Bug Reporter posted on Thu, 12 Jul 2018 22:00:58 -0400 as excerpted: > >> The lack of powerdevil may be the showstopper in this process. So I >> started looking for a config file that might disable kscreen. I did not >> find any yet, but I did find kscreen-doctor. This might be the way to >> leave kscreen installed and to manage it the way one would manage >> screens with xorg conf files or with xrandr. >> >> Interestingly, `kscreen-doctor -i` tells me: Preferred KScreen backend : >> KSC_XRandR.so >> >> KSC_XRandR.so: /usr/lib/qt/plugins/kf5/kscreen/KSC_XRandR.so >> I like xrandr as well as arandr (GUI). Now that I have some additional experience using those tools, I would like to disable or remove kscreen. As Duncan suggested, this seems to be a good way to solve my screen management headaches. I can apply layouts manually using xrandr (with an alias or script) or I can use arandr, which has all the features I used in kscreen plus more (e.g., saving and restoring layouts). Having both kscreen and xrandr / arandr appears to create conflicts. In some testing I just did, arandr would not apply a screen layout while kscreen had the monitors disabled. We had to use kscreen to do the task. Without kscreen installed, arandr worked perfectly. However, I do not want to remove powerdevil, therefore, I cannot remove kscreen. I looked at laptop-mode-tools and I did not like what I saw. It looks very dated. I'm not confident it will work that well on modern hardware. For example, I'm running NVMe drives. I don't want to get diverted from the task at hand by having to solve a bunch of power management issues, so powerdevil has to stay installed -- but I want to disable kscreen. In addition to KSC_XRandR11.so, which me mentioned previously, I see KSC_Fake.so, and that prompts a question. # ls /usr/lib/qt/plugins/kf5/kscreen/ total 504 drwxr-xr-x 1 root root136 Jun 27 12:50 . drwxr-xr-x 1 root root490 Jun 20 21:45 .. -rwxr-xr-x 1 root root 100176 Jun 26 09:15 KSC_Fake.so -rwxr-xr-x 1 root root 104360 Jun 26 09:15 KSC_KWayland.so -rwxr-xr-x 1 root root 67408 Jun 26 09:15 KSC_QScreen.so -rwxr-xr-x 1 root root 75600 Jun 26 09:15 KSC_XRandR11.so -rwxr-xr-x 1 root root 157608 Jun 26 09:15 KSC_XRandR.so What would happen if I copy KSC_XRandR11.so to KSC_XRandR11.so.bak and then copy KSC_Fake.so to KSC_XRandR11.so? I wonder if that would render kscreen "disabled" while leaving it installed. Any thoughts on this?
Re: plasma5 screen management going wrong
On Thursday July 12 2018 22:00:58 Bug Reporter wrote: Hi, >I don't know exactly what that is, but the name gives me the feeling >that kscreen-doctor might be able to be used like xrandr... any >thoughts? FWIW, I think kscreen is mostly a wrapper around XR, esp. the control panel that allows you to define multi-head layouts. Admittedly I only know the KDE4 version, but that just works, even for probably non-foreseen applications where you connect an AV amp for audio-out only. There I need to add an XR definition so I can send the amp a pure mirror image of my laptop screen. Correction: I did have to do very similar things (and they worked the same way) on a KaOS VM but I lost that one months ago because of corrupted upgrade. I *have* picked up noise about less-than-ideal multi-head support in Plasma (4 or 5) but never checked them out in depth because for now my main, multihead workstation is still a Mac. I can confirm though that connecting an additional display to my KDE4 desktop wasn't as pleasant an experience as it is on my Mac; loss of fluidity and completely messed-up mouse tuning. And that was not some crazy high res screen. My 2 cents: if this used to work for you and it stopped after a recent upgrade (esp. a Plasma one you can identify), bring this up in a more appropriate location where the Plasma devs will see it. That could be an actual bug reporter if you're certain that it worked as it should be before and no longer does, and that this is not a result of a corrupted config file somewhere (easy to check by creating a temp. fresh account). Depending on the distribution you're using you'd either report it to the distro (for known "branded" or "lagging" distros like Ubuntu) or else directly to bugs.kde.org . But the plasma-devel ML could be an appropriate place to ask if anything has changed that you should know about, and maybe forum.kde.org has an appropriate section too. R
Re: plasma5 screen management going wrong
Bug Reporter posted on Thu, 12 Jul 2018 22:00:58 -0400 as excerpted: > The lack of powerdevil may be the showstopper in this process. So I > started looking for a config file that might disable kscreen. I did not > find any yet, but I did find kscreen-doctor. This might be the way to > leave kscreen installed and to manage it the way one would manage > screens with xorg conf files or with xrandr. > > Interestingly, `kscreen-doctor -i` tells me: Preferred KScreen backend : > KSC_XRandR.so > > KSC_XRandR.so: /usr/lib/qt/plugins/kf5/kscreen/KSC_XRandR.so > > I don't know exactly what that is, but the name gives me the feeling > that kscreen-doctor might be able to be used like xrandr... any > thoughts? A *.so file indicates a "shared object", aka a "library", in MS Windows terms a DLL, dynamic-link-library. The extension and API used here is RandR, Resolution and Rotation. The X in front is because it's an X extension. And the KSC is either kscreen or possibly KDE software collection, likely the former tho I'm not sure. Presumably there's a different backend for wayland, this being the one for xorg. (I'm guessing this is part of the libkscreen package, which as I said earlier I don't have installed/merged here, so I can't as easily look up what package it belongs to as I could were it installed. So basically KSC_XRandR.so is simply the KDE shared-object library wrapping the xorg RandR extension API that both kscreen and xrandr use. Meanwhile... [kscreen-doctor --help output snipped] > I do not see a man page for kscreen-doctor and I don't see it discussed > on any wikis. Does anyone here have any experience using it? > > I would like to know what the modes numbers mentioned above are. For > example, what is mode 4 in "output.eDP-1.mode.4"? I had come across kscreen-doctor at one point, but like you got a bit frustrated at the lack of documentation, tho as indicated it seems a CLI method of interacting with kscreen. But for my purposes xrandr already did what I needed at the CLI, with plenty of documentation, so rather than mess around with the misbehaving kscreen and try to figure out kscreen-doctor some more, I just unmerged the whole thing and switched back to the generic X solution, xrandr while X was running, xorg.conf to configure how it starts up. At least that way I had (a) something that worked pretty much as documented and as I needed, and (b) quite a bit of documentation to tell me how to convert what was in my head to the appropriate xrandr commandline and/or xorg.conf snippets. -- 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
Re: plasma5 screen management going wrong
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
Re: plasma5 screen management going wrong
On Thu, Jul 12, 2018 at 7:06 PM, Bug Reporter wrote: > On Thu, Jul 12, 2018 at 6:03 PM, Bug Reporter wrote: >> see below >> >> On Thu, Jul 12, 2018 at 2:20 AM, Duncan <1i5t5.dun...@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.dun...@cox.net> wrote: > Bug Reporter posted on Sun, 01 Jul 2018 21:17:29 -0400 as excerpted: > >> 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? > > YES. > >> >> - Upon undocking, I assume I would run another randr script to disable >> the external monitors, then I would undock the laptop. > > YES > >> >> - 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. > >> >> - 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? > > I don't know. I did not create any xorg.conf files yet. Will I need to > create them? > >> >> - 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. > > 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? The lack of powerdevil may be the showstopper in this process. So I started looking for a config file that might disable kscreen. I did not find any yet, but I did find kscreen-doctor. This might be the way to leave kscreen installed and to manage it the way one would manage screens with xorg conf files or with xrandr. Interestingly, `kscreen-doctor -i` tells me: Preferred KScreen backend : KSC_XRandR.so KSC_XRandR.so: /usr/lib/qt/plugins/kf5/kscreen/KSC_XRandR.so I don't know exactly what that is, but the name gives me the feeling that kscreen-doctor might be able to be used like xrandr... any thoughts? # /usr/bin/kscreen-doctor --help Usage: /usr/bin/kscreen-doctor [options] [output.. output..setting [...]] kscreen-doctor allows to change the screen setup from the command-line. Setting the output configuration is done in an atomic fashion, all settings are applied in a single command. kscreen-doctor can be used to enable and disable outputs, to position screens, change resolution (mode setting), etc.. You should put all your options into a single invocation of kscreen-doctor, so they can all be applied at once. Usage examples: Show output information: $ kscreen-doctor -o Output: 1 eDP-1 enabled connected Panel Modes: Modes: 1:800x600@60 [...] Geometry: 0,0 1280x800 Output: 70 HDMI-2 enabled connected HDMI Modes: 1:800x600@60 [...] Geometry: 1280,0 1920x1080 Disable the hdmi output, enable the laptop panel and set it to a specific mode $ kscreen-doctor output.HDMI-2.disable output.eDP-1.mode.1 output.eDP-1.enable Position the hdmi monitor on the right of the laptop panel $ kscreen-doctor output.HDMI-2.position.0,1280 output.eDP-1.position.0,0 Set resolution mode $ kscreen-doctor output.HDMI-2.mode.1920x1080@60 Set scale (note: fractional scaling is only supported on wayland) $ kscreen-doctor output.HDMI-2.scale.2 Set rotation (possible values: none, left, right, inverted) $ kscreen-doctor output.HDMI-2.rotation.left Options: -h, --help Displays this help. -i, --info Show runtime information: backends, logging, etc. -j, --json Show configuration in JSON format -o, --outputsShow outputs -d, --dpms Display power management (wayland only) -l, --log Write a comment to the log file Arguments: config Specific output settings are separated by spaces, each
Re: plasma5 screen management going wrong
On Thu, Jul 12, 2018 at 6:03 PM, Bug Reporter wrote: > see below > > On Thu, Jul 12, 2018 at 2:20 AM, Duncan <1i5t5.dun...@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.dun...@cox.net> wrote: Bug Reporter posted on Sun, 01 Jul 2018 21:17:29 -0400 as excerpted: > 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? YES. > > - Upon undocking, I assume I would run another randr script to disable > the external monitors, then I would undock the laptop. YES > > - 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. > > - 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? I don't know. I did not create any xorg.conf files yet. Will I need to create them? > > - 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. 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?
Re: plasma5 screen management going wrong
see below On Thu, Jul 12, 2018 at 2:20 AM, Duncan <1i5t5.dun...@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.dun...@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?
Re: plasma5 screen management going wrong
t;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 --o ... 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
Re: plasma5 screen management going wrong
Bug Reporter posted on Sun, 01 Jul 2018 21:17:29 -0400 as excerpted: > Which project should this bug be reported to? > > Is this "laptop display" box that pops up part of plasma5? I assume it > must be, but I'm not using a laptop. > > On Sat, Jun 30, 2018 at 6:26 PM, Bug Reporter > wrote: > >> With the most recent update of KDE, screen management is acting up. I >> have a desktop with 3 monitors. After this update, every time I log >> into Plasma5, several things happen: >> >> 1. I get a popup asking me about laptop display options. This is not a >> laptop. Furthermore, the options presented are confusing. None of them >> look viable. I have been leaving it unchanged. However, I do not want >> this dialog every time I log in when my attached screens have not >> changed. >> >> 2. The arrangement of my screens has changed (e.g., the screen that >> should be in the middle is arranged on the left or right, etc.) >> >> 3. the primary display may have changed too. >> >> In general, other settings may be lost or changed too, such as the >> locations and settings of my panels. That appears to be a consequence >> of the screen arrangement being screwed up. >> >> $ qmake --version QMake version 3.1 Using Qt version 5.11.1 in /usr/lib >> >> $ plasmashell --version plasmashell 5.13.2 >> >> $ dolphin --version dolphin 18.04.2 >> >> $ uname -a Linux 4.17.2-1-ARCH #1 SMP PREEMPT Sat Jun 16 11:08:59 UTC >> 2018 x86_64 GNU/Linux >> > Which project should this bug be reported > to?Is this laptop display box that > pops up part of plasma5? I assume it must be, but Im not using a > laptop. class="gmail_quote">On Sat, Jun 30, 2018 at 6:26 PM, Bug Reporter dir="ltr">mailto:bugreporte...@gmail.com; > target="_blank">bugreporte...@gmail.com > wrote: dir="ltr">With the most recent update of KDE, screen management is > acting up. I have a desktop with 3 monitors. After this update, every > time I log into Plasma5, several things > happen:1. I get a popup asking me about laptop > display options. This is not a laptop. Furthermore, the options > presented are confusing. None of them look viable. I have been leaving > it unchanged. However, I do not want this dialog every time I log in > when my attached screens have not > changed.2. The arrangement of my screens > has changed (e.g., the screen that should be in the middle is arranged > on the left or right, etc.)3. the primary > display may have changed too.In general, > other settings may be lost or changed too, such as the locations and > settings of my panels. That appears to be a consequence of the screen > arrangement being screwed up.$ qmake > --versionQMake version 3.1Using Qt version 5.11.1 in > /usr/lib$ plasmashell --versionplasmashell 5.13.2$ > dolphin --versiondolphin 18.04.2$ uname -aLinux > 4.17.2-1-ARCH #1 SMP PREEMPT Sat Jun 16 11:08:59 UTC 2018 x86_64 > GNU/Linux > First, please avoid the HTML gibberish. HTML email is a major security vulnerability if it's actually displayed as HTML, with the various elements allowed to fetch and/or execute, and as I hope you can see (but you may not depending on how your client reacts to conventionally quoted HTML), if the HTML is displayed as plain-text, that's not particularly pretty either. So set plain text for mailing lists and avoid having us old timers shake our cane at you. =:^) (I wish the kde lists did what the kernel lists do, auto-reject HTML mail with a message saying to send in plain text, but since they don't, this is the manual version.) Second, please reply in-context under the contextual-quote you're replying to. It makes further replies in-context /so/ much easier. I almost just skipped this rather than bother, but decided to send the requests along with the reply to the question, instead. As for the question... This is likely the kscreen component, or libkscreen loaded by something else (maybe solid, which is supposed to do hardware detection?) . After fighting with similar issues on and off since at least kde3 era, thru 4 and now plasma5 -- for whatever reason kde just doesn't seem to be able to take a carefully configured xorg setup and leave it alone, it always wants to mess it up in some way or another -- after the last iteration, I finally unmerged/uninstalled those two components (nothing else I had installed actually required them, solid is installed but if it can use them at least it doesn't complain without them), and while I can't use kde/plasma/kscreen to change the multi-monitor layout now since it's not installed any longer, at least things stay the way I have them configured in xorg.conf, and plasma doesn't complain or want to reorganize things its own way any longer. 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. The trouble in this case seems to be that kscreen assumes a laptop with a monitor attached, and that all
Re: plasma5 screen management going wrong
Which project should this bug be reported to? Is this "laptop display" box that pops up part of plasma5? I assume it must be, but I'm not using a laptop. On Sat, Jun 30, 2018 at 6:26 PM, Bug Reporter wrote: > With the most recent update of KDE, screen management is acting up. I have > a desktop with 3 monitors. After this update, every time I log into > Plasma5, several things happen: > > 1. I get a popup asking me about laptop display options. This is not a > laptop. Furthermore, the options presented are confusing. None of them look > viable. I have been leaving it unchanged. However, I do not want this > dialog every time I log in when my attached screens have not changed. > > 2. The arrangement of my screens has changed (e.g., the screen that should > be in the middle is arranged on the left or right, etc.) > > 3. the primary display may have changed too. > > In general, other settings may be lost or changed too, such as the > locations and settings of my panels. That appears to be a consequence of > the screen arrangement being screwed up. > > $ qmake --version > QMake version 3.1 > Using Qt version 5.11.1 in /usr/lib > > $ plasmashell --version > plasmashell 5.13.2 > > $ dolphin --version > dolphin 18.04.2 > > $ uname -a > Linux 4.17.2-1-ARCH #1 SMP PREEMPT Sat Jun 16 11:08:59 UTC 2018 x86_64 > GNU/Linux >
plasma5 screen management going wrong
With the most recent update of KDE, screen management is acting up. I have a desktop with 3 monitors. After this update, every time I log into Plasma5, several things happen: 1. I get a popup asking me about laptop display options. This is not a laptop. Furthermore, the options presented are confusing. None of them look viable. I have been leaving it unchanged. However, I do not want this dialog every time I log in when my attached screens have not changed. 2. The arrangement of my screens has changed (e.g., the screen that should be in the middle is arranged on the left or right, etc.) 3. the primary display may have changed too. In general, other settings may be lost or changed too, such as the locations and settings of my panels. That appears to be a consequence of the screen arrangement being screwed up. $ qmake --version QMake version 3.1 Using Qt version 5.11.1 in /usr/lib $ plasmashell --version plasmashell 5.13.2 $ dolphin --version dolphin 18.04.2 $ uname -a Linux 4.17.2-1-ARCH #1 SMP PREEMPT Sat Jun 16 11:08:59 UTC 2018 x86_64 GNU/Linux
