SUMMARY Starting from Plasma 5.18.0, XRandR scaling set via SDDM DisplayCommand is reset to 1.0 after logon. STEPS TO REPRODUCE 1. Enable DisplayCommand in /etc/sddm.conf 2. In the display command script, use 'xrandr ... --scale 2.0' to scale a display Personally I scale my 1080p displays so that I can have a proper Plasma global scaling for the 4K one: xrandr --fb 11520x2160 \ --output DP-0 --auto --scale 2.0 --dpi 256 --panning 3840x2160+0+0 --pos 0x0 \ --output DP-3 --auto --primary --scale 1.0 --dpi 163 --panning 3840x2160+3840+0 --pos 3840x0 \ --output HDMI-0 --auto --scale 2.0 --dpi 205 --panning 3840x2160+7680+0 --pos 7680x0 OBSERVED RESULT Scaling looks alright on SDDM login dialog, however it's disabled during the splash screen. EXPECTED RESULT XRandR scaling remains untouched after logon as it did in 5.17.5 SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.18.0 KDE Frameworks Version: 5.67.0 Qt Version: 5.14.1 Kernel Version: 5.5.3-zen1-1-zen OS Type: 64-bit ADDITIONAL INFORMATION I'm using Nvidia proprietary driver nvidia-dkms 440.59-7
Btw to make matters worse, the panning areas of the 1080p displays are not reconfigured accordingly after scaling is reset to 1.0, so when I move the cursor around they sometimes show empty framebuffer areas.
Transform is set in https://cgit.kde.org/libkscreen.git/tree/backends/xrandr/xrandroutput.cpp#n392. Normally this is set to identity matrix, but if one output is replicated it might be set differently such that the output fits the into the replica. If you have some manual scripting going on you can try to reapply it after KScreen daemon has done its work. In general KScreen can't respect manual scripting and will just override such efforts when it applies its own settings via X11 protocol. What could be a goal is to allow setting the scale individually for outputs in KScreen via transform matrices. But it's not on my priority list right now.
*** Bug 417541 has been marked as a duplicate of this bug. ***
May I know what the best way is to tell whether KScreen has done applying its configuration?
(In reply to Roman Gilg from comment #2) > In general KScreen can't respect manual scripting and will just override > such efforts when it applies its own settings via X11 protocol. sure, but in this very case, wouldn't it be possible to query the set parameters first and then apply the changes over the set parameters? AFAIK the scaling factors (transform matrix) can be retrieved and as long as kscreen doesn't want to change them, leave them as is. of course, once kscreen offers a way to set scaling factors per output, this settings should take precedence. btw. why did the behavior change in plasma 5.18.0 as it worked perfectly before?
> sure, but in this very case, wouldn't it be possible to query the set > parameters first and then apply the changes over the set parameters? This is the behaviour that makes most sense to me as well. And I guess even if at some point in the future all the wayland/nvdia/etc stuff are figured out and the multi-head support in Plasma can be perfected, there are always gonna be a few users who'd like to use some 'weird' configurations, e.g. special panning/transform, which are not needed to be supported by Plasma via GUI at all, but at the same time shouldn't be overridden by Plasma either. If querying the current parameters is too much of a hassle, I reckon Plasma should at least allow users to disable the KScreen settings.
Can we reopen this ticket? Even putting the proposed better solution above aside, so far I haven't found a stable way to detect whether KScreen has done applying its configurations. Hence although I've already got the needed scripts and 'try to reapply it after KScreen daemon has done its work', currently the only option I've got is to manually run it every time and tbh it's not a very pleasant experience.
Let's reopen it for feedback and maybe someone finds a simple solution for it. Personally I won't work on a fix though. Could the KScreen daemon binary be diverted / renamed? You won't be able to use the ui afterwards but since you are using xrandr anyway.
(In reply to Roman Gilg from comment #8) > Could the KScreen daemon binary be diverted / renamed? I deleted /usr/share/dbus-1/services/org.kde.kscreen.service in my system and now KScreen no longer applies its configuration upon login. (But you'll still need something like a pacman hook to automatically remove this file after every upgrade as there is atm no standard way to disable a D-Bus service [1].) > Let's reopen it for feedback and maybe someone finds a simple solution for it. May I know whether Plasma actually depends on KScreen? Currently in Arch Linux libkscreen is a dependency of plasma-workspace but if Plasma can in fact work without it, then a (temporary) workaround for this issue could be as simple as asking the package maintainers to remove KScreen from Plasma's mandatory dependency list. [1] https://gitlab.freedesktop.org/dbus/dbus/issues/70
This isn't a supported use case in conjunction with KScreen, sorry. If you want to do things manually, you're welcome to disable KScreen.