UHD (4K) + WUXGA monitors + nvidia blob + Plasma = mismatched scale issues?

I’ve a dual monitor setup with identical 24" 60 Hz WUXGA (1920 x 1200 16:10) LCD monitors.

I’m thinking of switching one of them for a 28" 60Hz non-gaming UHD (3840 x 2160 16:9) Philips 288p6LJEB monitor. I couldn’t find it’s response time, but as it is has a TN panel and it’s (mostly) for work it shouldn’t be an issue, I hope.

This is a vanilla LEAP 42.3 desktop work box. If necessary it can be upgraded to 15.0, although I’d rather wait for 15.1. Current configuration is:

  • kernel 4.4.155-68-default
  • KDE Frameworks 5.32.0
  • Qt 5.6.2
  • SDDM Display Manager

Video card is a GTX1050 2GB. It supports UHD in both DisplayPort 1.4 and HDMI 2.0b at 60Hz (and higher), so no issues here.

From this post https://forums.opensuse.org/showthread.php/531742-KDE-and-two-displays-with-diff-resolutions it seems that I may not be able to set different scales for each monitor. In both system-settings>display and in nvidia-settings I can set different resolutions, but only system-settings has a scale setting (apparently for both displays as one), and none that I could see in nvidia-settings.

I don’t want to reduce the UHD panel resolution, it would defeat the whole purpose of using it.

Note: the UHD panel turns 90°, but I don’t think I’ll use portrait mode much.

My question is: will I have issues with different icon/decorations/text sizes from one screen to another (perhaps mitigated by the 4" difference between screen diagonals) or is there a per-monitor scale setting?

Thanks,

Note: the LCD monitors only have DVI-D and VGA ports. both are connected to DVI, one with a DVI-to-HDMI cable.

www.usa.philips.com say response time is 5 ms, www.amazon.com say it is just 1 ms…

Liar, liar, pants on fire.

Actually it is 1ms (Gray to Gray); 5ms typical.

So not a lie, just misleading.

See here for an idea on how to scale a display in a dual monitor configuration…
https://wiki.archlinux.org/index.php/HiDPI#Multiple_external_monitors

Great, this will probably work.

The monitor should arrive in a couple of weeks, then we’ll see.

Thank you very much, Deano!

Follow-up:

Installed new 4K monitor, older 1920x1200 monitor to the right.

At first run everything too small on 4K (as expected), normal on older monitor.

To fix 4K, best option to me was change DPI on system-settings from default (~96) to 157. This is the actual dpi, calculated from monitor dimensions and resolution. Usually a divisible-by-eight dpi is used, but in this case 152 and 160 would cause a bit of dithering on narrow letters like “i” and “l”.

I also enabled light hinting and made slight adjustment to fonts size, and set QT_AUTO_SCREEN_SCALE_FACTOR=0 environment variable. I’m not sure what effect this had, if any.

Then, of course, everything was too big on the older monitor. Fixing this was a bit problematic. After much experimentation, what worked best was to run

xrandr --output DVI-D-0 --scale 1.6x1.6

soon after KDE starts. There was no need to force (full) composition pipeline in nvidia-settings.

Weirdly, setting this as an autostart script in system-settings>start & shutdown>autostart didn’t work as expected, either set to autostart before or after KDE. This would mess with the desktop settings, repositioning the second monitor on top of the first, and changing the scale setting wrongly at system-settings>screen & monitor>screen. Running it from the desktop after KDE start works as expected.

Also, a vertical panel on the right of the older monitor would be scaled and re-positioned to the middle of the screen. I ended up removing it.

I’m having the old recurrent problem of windows extending under the bottom panel on the new monitor, even with it set to always visible. Sometimes it works as it should, but mostly not. It’s annoying, and I couldn’t find a workaround yet.

Pure speculation here, but I wonder if disabling the kscreen2 service (via Startup and Shutdown Background Services) might be needed to prevent conflict with any manual configuration?

“Usually” by whom or what? Divisible-by-12 is bested only by divisible-by-24, both better than by-8. Maybe your 157 is close enough to by-12=156 to do well enough most of the time with the fonts you use. I often use 143 to avoid the 1.5 HiDPI breakpoint 144 that web browsers use.

My xrandr startup scripts always go in /etc/X11/xinit/xinitrc.d/ and always work as expected. Maybe that yours didn’t is actually a bug, and might be worked around by having xrandr specify both outputs and modes and position and fbmm/dpi along with scale.

If you click system-settings dpi setting up/down arrows you’ll see they change in multiples of 6/8/12/14/24, using a not obvious internal logic, as it depends on the initial dpi value. Initially the changes were 8 by 8, so I assumed it would be that way always, my mistake, thank you for correcting me. Anyway, I tried 156 at the time - as well as many others - and 157 gave the best result. So 157 it is.

TBH I don’t really care, the desktop script is just a click away after each (very infrequent) boot. Woks very well for me, although Deanno’s suggestion above may be a more efficient solution. I may try it sometime I’m not worried about messing my desktop once again.

Also, a vertical panel on the right of the older monitor would be scaled and re-positioned to the middle of the screen. I ended up removing it.

Further on this, in the old scaled down monitor, panels, widgets and wallpapers only appear in the top left 63% of the screen (63% = 1/1.6, the scale down factor).

Aesthetic solutions were to use a solid background black color or a wallpaper with black background, like openSUSE’s green lamp one.

For future reference, two options to set VirtualBox for 4K. I use two windows-only structural analysis applications. Their icons scale very differently:

  1. SAP - application icons do scale, although they get somewhat smaller at 4K, but still usable.

    VM configuration>monitor:
    2D and 3D acceleration enabled
    scale factor 100% - this means VBox will map 1 host display pixel to 1 guest display pixel, without scaling, i.e., in windowed mode W7 see the max display res of 3840 x 1953 (1200 less the lines used by openSUSE panel)

    W7 guest:
    display scale 180%. this is set at the custom text size (DPI) option (W7 does not give dpi in dpi, but as a percentage)
    pointer scale set to normal.

    Guest welcome/logon screen text & cursor are small, but readable.

  2. CYPE 3D - icons don’t scale at all, are so tiny at 4K as to be unusable.

    VM configuration>monitor:
    2D and 3D acceleration enabled
    scale factor 180% - this is how much VBox will scale down the 4K display resolution for the guest, i.e., 3840/1.8 = 2133 horizontal, etc. In my VM in windowed mode, W7 see the max display res of 2133 x 1085 (less than 2160/1.8 = 1200 due to the lines used by openSUSE panel)

    W7 guest:
    display scale 100% (same as standard dpi, only W7 does not give dpi in dpi, but as a percentage)
    pointer scale set to extra large.

    Application icons and guest welcome/logon screen text & cursor are normal size.

    Some unusual scale settings like 157 (VM or guest) will make the mouse very, very laggy, although the guest monitor is at 60Hz, same as the 4K panel.

    Performance does not feel as good as with the first configuration option, but is usable.

Yesterday even with 180% scale factor the VM got insuportably laggy again. Setting it to 200% solved it, I didn’t try other scales.

200% is integer scaling (X2), more efficient than floating point (180% = X1.8).

Yes, I’m aware of that. My feeling was that at 180% performance was OK, but on further testing it does carry a penalty. I tested again just now, and at 180% the desktop was perceptibly slower, although much less than the last time. For example, at the first run there was no unusual CPU usage, then the second time virtualbox was using maybe half a core just to keep the display updated. Anyway, from now on I’ll use 200%.

Now I’m trying to deal with the real tiny fonts on some native java apps. Their size seem to be hardcoded. There is still some way to go to make 4K work OOTB on openSUSE. Perhaps when Wayland goes mainstream (if ever) :slight_smile:

I think that’s a Java “feature”. Every time I’ve tried to use a Java app, I’ve been unable to make its fonts bigger than the smallest size the OS or DE is capable of rendering, usually 1/4 the size or smaller than what I need, thus making the Java app useless regardless of the screen density or resolution.

The support for PDFStudio, an excellent - for my needs - paid app, had no solution either. They suggested changing the DM from sddm (I run PLasma) to gdm - no joy. Also to use gtk+ theme, but the theme selector in PDFStudio settings only list nimbus and Metal. And this last one, twice…

They passed the issue to their developers, but don’t expect a fast solution.

My workaround for now is to use a second small script to turn scaling off on the second monitor:

#!/bin/bash
xrandr --output HDMI-0 --scale 1.0x1.0

(note that I moved the 4K display to DisplayPort and the WUXGA one to HDMI)

Now if I want to use a java app I “unscale” the second display and open the app there. After using the app I “rescale” it with:

#!/bin/bash
xrandr --output HDMI-0 --scale 1.6x1.6

For future reference, Leap 15.1 VBox 6.0.12 VM scale 200% guest 100% is very laggy with new VboxSVGA driver and 3D acceleration enabled. This does not occur with the older VboxVGA driver, but it will be deprecated. The third available option, VMware’s VMSVGA, does not autoscale.

So for now it seems better to run VboxSVGA with 3D accel disabled.

Just in case anyone comes across this old thread as I did… Deano was correct kscreen2 can be a source of problems.

I’m using the nvidia proprietary driver with two desktop monitors with different resolutions. In my case kscreen2 was in conflict with what was set with xrandr, the symptom being incorrect restoration of the right hand scaled monitor on login. From my own admin notes:

For 144 DPI on the 4K 27 inch monitor on left, 24 inch 1920x1200 monitor on right:
    - Create /etc/X11/xinit/xinitrc.d/50-xrandr.sh contents should be:
       xrandr --output DP-4 --auto --output DP-0 --auto --scale 1.75x1.75 --right-of DP-4
    - To stop kscreen2 from messing with what was set by X11 startup disable Kscreen 2
       in the KDE settings -> Startup and Shutdown -> Background Services 

You can use xrandr --listmonitors to find out the appropriate monitor ID’s.