Automatic Display-Scaling Changing when using a Monitor on KDE 6.3

Hello again :slight_smile:

I am on the Fedora 42 KDE Beta and I am very, very happy with the improvements on Display Scaling. This got me thinking: I use a Laptop with a 3K Built-In Display. When I am using the Laptop only, I want a Display Scale of 170%. But I often use the Laptop with a USB-C Monitor and because the Laptop is a bit further away, I would like to change the scaling to 195%, when using the Monitor.

So is it possible, to make the scaling change automatically, when connecting or disconnecting the Monitor? Only on the Internal Display, the External Monitor should always be on 135%.

Thanks for your help.

Report the bug on kwin under bugs.kde.org

Make sure to give infos from kinfo, kscreendoctor and journalctl

Am I understanding this correctly, that my question if this is possible should be already the standard behaviour and it’s a bug because it’s not working?

You misunderstood. They manage the Issues there. Have a look what you find on their bug tracker and report with more info’s direct with KDE.

That is a pretty specific feature request, using the presence or absence of another device to configure the scaling of the internal display. I don’t think this feature exists and I doubt there is a anything about it in KDE’s bugtracker like others suggested.

You can use kscreen-doctor to programmatically modify settings of your display. E.g., on my laptop, I can change the scaling of the internal display using the following commands (using the two scaling factors that you want to use):

~ > kscreen-doctor output.eDP-1.scale.1.7
~ > kscreen-doctor output.eDP-1.scale.1.95

You can find out what output devices you have by running

~ > kscreen-doctor -o
Output: 1 eDP-1
        enabled
        connected
        priority 1
        Panel
        Modes:  1:2880x1800@60*!  2:1920x1200@60  3:1920x1080@60  4:1600x1200@60  5:1680x1050@60  6:1280x1024@60  7:1440x900@60  8:1280x800@60  9:1280x720@60  10:1024x768@60  11:800x600@60  12:640x480@60  13:1600x1200@60  14:1280x1024@60  15:1024x768@60  16:2560x1600@60  17:1920x1200@60  18:1280x800@60  19:2880x1620@60  20:2560x1440@60  21:1920x1080@60  22:1600x900@60  23:1368x768@60  24:1280x720@60 
        Geometry: 0,0 1440x900
        Scale: 2
        Rotation: 1
        Overscan: 0
        Vrr: incapable
        RgbRange: unknown
        HDR: disabled
        Wide Color Gamut: disabled
        ICC profile: none
        Color profile source: EDID
        Color power preference: prefer efficiency and performance
        Brightness control: supported, set to 15% and dimming to 100%

For a first proof of concept, you can manually run these commands when you connect or disconnect your external display.

If that works, you can think about automating this step. Because it is an external USB-C display (and not simply another DP or HDMI output on your graphics card) I think a couple of udev rules that run these commands when the external display is connected and disconnected should do the trick. However, I have no idea what events you would need to match for that.

Thanks for your answer, I’ll try it on saturday.

I know this request seems specific at first but if you think about it, your system remembers what scaling you used for which monitor, how the monitor were aligned, what refresh rate you set for that monitor and so on. So why isn’t it possible to include the same parameters for the internal Display when docking to a Monitor?

As a Casual User, this idea doesn’t seem too far fetched for me.

It also makes sense on the other hand, since the scaling is affected by the Distance that you view the monitor in. When docked and opened, a Laptop is mostly further away than when using it directly on a desk. Thus a higher scaling would be preferred.

Thanks, I’ll take a look. I hope this isn’t above my knowledge, since I’m just an average user :slight_smile:

I get where you are coming from, with how far away your laptop display is from your eyes. However, your operating system does not know about the physical arrangement of your displays in your 3D world. Because the system does not know about that, you are asking it to approximate “physical distance in space and my resulting preferred scaling factor” by “which set of displays is connected and derive my preferred scaling factor from that”. IMHO, that is not a good, generic way to do something like that.

Looking at it from a technical perspective, most things are actually specific to a display and do not depend on the combination of displays currently connected: the resolution of a display, the refresh rate, the scaling factor, color settings, etc. are all properties of a display. Connect a second one and I doubt you suddenly want to change the resolution or the refresh rate of the first one. Sure, conceptually, you could move all the per-display settings to displays entities in display groups and store them that way. But that would duplicate the settings and I would seriously question the design if I had to change, say, the refresh rate of a display X times just because this display is part of X groups and every time another group is activated it goes back to the previously stored setting in that group. (Plus, with this design a new combination of displays, for which you do not have a group and per display settings yet, suddenly becomes a major headache: From which other group do you take the per-display settings? Do you expect the user to go through and reconfigure each display in this new group?)

The one thing that really is dependent on a set of displays in a multi-display setup is their actual physical arrangement, like “a single row, display A on the left, B in the middle, and C on the right” or “A centered above B on the left and C on the right”. And that’s why this is stored per group, it would be a major pain to reconfigure this every time the same set of displays is connected.

That’s what I meant when I called it a pretty specific feature request. Natural for you and the way you work with your systems but not necessarily for a large enough group of users to justify the time to implement this, with all the corner cases that suddenly appear. But that is the great thing about Linux/KDE/FOSS/…, if you have specific requirements, you can customize and tailor the system to your needs.