You are not logged in.

#1 2021-11-11 15:35:35

Andy3153
Member
Registered: 2018-12-24
Posts: 62

[SOLVED]Messed up scaling with new Arch update

I have seen this, but it didn't help me all that much.

I just did an update where most likely Xorg got updated as well, and it messed up the display scaling.

I tried creating the file /etc/X11/xorg.conf.d/90-monitor.conf like in this, but it didn't work. Maybe I am not getting the ID of the display correctly.

/etc/X11/xorg.conf.d/90-monitor.conf
---------------------------------------------------------

Section "Monitor"
    Identifier             "eDP-1-1"
    DisplaySize            344 194    # In millimeters
EndSection
$ xrandr

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
   1920x1080    240.00*+  60.01    59.97    59.96    59.93    60.00  
   1680x1050     59.95    59.88  
   1400x1050     74.76    59.98  
   1600x900      59.99    59.94    59.95    59.82  
   1280x1024     85.02    75.02    60.02  
   1400x900      59.96    59.88  
   1280x960      85.00    60.00  
   1440x810      60.00    59.97  
   1368x768      59.88    59.85  
   1280x800      59.99    59.97    59.81    59.91  
   1152x864      75.00  
   1280x720      60.00    59.99    59.86    59.74  
   1024x768      85.00    75.05    60.04    85.00    75.03    70.07    60.00  
   1024x768i     86.96  
   960x720       85.00    75.00    60.00  
   928x696       75.00    60.05  
   896x672       75.05    60.01  
   1024x576      59.95    59.96    59.90    59.82  
   960x600       59.93    60.00  
   832x624       74.55  
   960x540       59.96    59.99    59.63    59.82  
   800x600       85.00    75.00    70.00    65.00    60.00    85.14    72.19    75.00    60.32    56.25  
   840x525       60.01    59.88  
   864x486       59.92    59.57  
   700x525       74.76    59.98  
   800x450       59.95    59.82  
   640x512       85.02    75.02    60.02  
   700x450       59.96    59.88  
   640x480       85.09    60.00    85.01    72.81    75.00    59.94  
   720x405       59.51    58.99  
   720x400       85.04  
   684x384       59.88    59.85  
   640x400       59.88    59.98    85.08  
   576x432       75.00  
   640x360       59.86    59.83    59.84    59.32  
   640x350       85.08  
   512x384       85.00    75.03    70.07    60.00  
   512x384i      87.06  
   512x288       60.00    59.92  
   416x312       74.66  
   480x270       59.63    59.82  
   400x300       85.27    72.19    75.12    60.32    56.34  
   432x243       59.92    59.57  
   320x240       85.18    72.81    75.00    60.05  
   360x202       59.51    59.13  
   360x200       85.04  
   320x200       85.27  
   320x180       59.84    59.32  
   320x175       85.27  
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
DP-1-0 disconnected (normal left inverted right x axis y axis)
DP-1-1 disconnected (normal left inverted right x axis y axis)
DP-1-2 disconnected (normal left inverted right x axis y axis)
DP-1-3 disconnected (normal left inverted right x axis y axis)

Note that in the XRandr output it actually tells me the right display sizes in milimeters (I have physically measured the display with a ruler to check). Why isn't Xorg getting it right? If XRandr can see it well, Xorg should, without any prior configuration, but Xorg can't get it right even with configuring it manually using that file I showed.


EDIT: (I use KDE) If I run xrandr --dpi 96 to set the DPI temporarily, then close every app I have open, kill plasmashell, latte-dock, then replace kwin with itself (kwin_x11 --replace) and start all these programs back again, the DPI gets set, as it should normally. But it's not good since I would have to do this everytime and I see it more as a workaround than a solution

Last edited by Andy3153 (2021-11-11 16:11:36)

Offline

#2 2021-11-11 15:39:54

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 26,718
Website

Re: [SOLVED]Messed up scaling with new Arch update

Well, no the Identifier of the display is clearly incorrect.  Remove the extra "-1" at the end of the Identifier.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2021-11-11 15:43:35

Andy3153
Member
Registered: 2018-12-24
Posts: 62

Re: [SOLVED]Messed up scaling with new Arch update

Trilby wrote:

Well, no the Identifier of the display is clearly incorrect.  Remove the extra "-1" at the end of the Identifier.

Oh, yeah, I have tried that the first time. It didn't work. Should I remove the first one too?

EDIT: tried doing that too, still didn't work. So, I've tried eDP-1, then eDP-1-1, then just eDP, and none worked.

Last edited by Andy3153 (2021-11-11 15:46:15)

Offline

#4 2021-11-11 15:55:33

seth
Member
Registered: 2012-09-03
Posts: 28,939

Re: [SOLVED]Messed up scaling with new Arch update

EDIT: (I use KDE) If I run xrandr --dpi 96 to set the DPI temporarily, then close every app I have open, kill plasmashell, latte-dock, then replace kwin with itself (kwin_x11 --replace) and start all these programs back again, the DPI gets set, as it should normally. But it's not good since I would have to do this everytime and I see it more as a workaround than a solution

Stop messing around w/ the monitor geometries, they're correct anyway.
The output has a physical DPI of 140 and the 1.21 X11 server adheres to that.

https://bbs.archlinux.org/viewtopic.php?id=271121

Offline

#5 2021-11-11 16:10:10

Andy3153
Member
Registered: 2018-12-24
Posts: 62

Re: [SOLVED]Messed up scaling with new Arch update

seth wrote:

EDIT: (I use KDE) If I run xrandr --dpi 96 to set the DPI temporarily, then close every app I have open, kill plasmashell, latte-dock, then replace kwin with itself (kwin_x11 --replace) and start all these programs back again, the DPI gets set, as it should normally. But it's not good since I would have to do this everytime and I see it more as a workaround than a solution

Stop messing around w/ the monitor geometries, they're correct anyway.
The output has a physical DPI of 140 and the 1.21 X11 server adheres to that.

https://bbs.archlinux.org/viewtopic.php?id=271121

I went into the thread you showed me and I saw a solution posted by someone in there to set the DPI inside SDDM (this), and, while it worked, I'm still curious why it is necessary now and it wasn't before this update.
I saw someone saying that something about DPI got changed in Xorg 21, but why was it changed if it broke for some people? Did it break for everyone? Did it break only for KDE users? There were people in that thread saying that GTK apps didn't have this problem, and they're right, Firefox didn't suffer any scaling issues while the rest of my DE did

And, also, this isn't the first time this happened to me. It happened to me an year ago maybe, on another system, but I didn't bother searching and I made font sizes smaller and called it a day. Was not a great fix

seth wrote:

The output has a physical DPI of 140

What do you mean? When I fixed it through SDDM I had to set it to 96

Last edited by Andy3153 (2021-11-11 16:12:20)

Offline

#6 2021-11-11 16:16:01

seth
Member
Registered: 2012-09-03
Posts: 28,939

Re: [SOLVED]Messed up scaling with new Arch update

What do you mean?

eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 194mm

You're assessing that this is correct, correct?
That's 1920/(344/25.4) x 1080/(194/25.4) = 141.77 x 141.40 DPI - the value "96" is technically incorrect and you probably adjusted the system to map 96 to be usable at 140 - either by using a too big font or some client side scale factor.

Reg. "why only KDE", I've no idea.

printenv

And also what is the size (in point) of your default UI font?

Offline

#7 2021-11-11 16:32:16

Andy3153
Member
Registered: 2018-12-24
Posts: 62

Re: [SOLVED]Messed up scaling with new Arch update

seth wrote:

What do you mean?

eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 194mm

You're assessing that this is correct, correct?
That's 1920/(344/25.4) x 1080/(194/25.4) = 141.77 x 141.40 DPI - the value "96" is technically incorrect and you probably adjusted the system to map 96 to be usable at 140 - either by using a too big font or some client side scale factor.

I haven't done any of that honestly, if it hasn't been done by default then I haven't touched anything until now. I set 96, and, well, it just looks right like before. I even compared screenshots to make sure and elements look the exact same size

seth wrote:
printenv
$ printenv

BROWSER=firefox
CASROOT=/usr
COLORFGBG=15;0
COLORTERM=truecolor
CSF_DrawPluginDefaults=/usr/share/opencascade/resources/DrawResources
CSF_EXCEPTION_PROMPT=1
CSF_IGESDefaults=/usr/share/opencascade/resources/XSTEPResource
CSF_LANGUAGE=us
CSF_MDTVTexturesDirectory=/usr/share/opencascade/resources/Textures
CSF_MIGRATION_TYPES=/usr/share/opencascade/resources/StdResource/MigrationSheet.txt
CSF_OCCTResourcePath=/usr/share/opencascade/resources
CSF_PluginDefaults=/usr/share/opencascade/resources/StdResource
CSF_SHMessage=/usr/share/opencascade/resources/SHMessage
CSF_STEPDefaults=/usr/share/opencascade/resources/XSTEPResource
CSF_ShadersDirectory=/usr/share/opencascade/resources/Shaders
CSF_StandardDefaults=/usr/share/opencascade/resources/StdResource
CSF_StandardLiteDefaults=/usr/share/opencascade/resources/StdResource
CSF_TObjDefaults=/usr/share/opencascade/resources/StdResource
CSF_TObjMessage=/usr/share/opencascade/resources/TObj
CSF_XCAFDefaults=/usr/share/opencascade/resources/StdResource
CSF_XSMessage=/usr/share/opencascade/resources/XSMessage
CSF_XmlOcafResource=/usr/share/opencascade/resources/XmlOcafResource
CUDA_PATH=/opt/cuda
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/3153/bus
DESKTOP_SESSION=plasma
DISPLAY=:0
DOTNET_CLI_TELEMETRY_OPTOUT=1
DRAWDEFAULT=/usr/share/opencascade/resources/DrawResources/DrawDefault
DRAWHOME=/usr/share/opencascade/resources/DrawResources
EDITOR=nvim
FILE_MANAGER=dolphin
GAMEMODERUNEXEC=env __NV_PRIME_RENDER_OFFLOAD=1 env __GLX_VENDOR_LIBRARY_NAME=nvidia env __VK_LAYER_NV_optimus=NVIDIA_only
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/andy3153/.gtkrc-2.0:/home/andy3153/.config/gtkrc-2.0
GTK3_MODULES=xapp-gtk3-module
GTK_MODULES=canberra-gtk-module:appmenu-gtk-module
GTK_RC_FILES=/etc/gtk/gtkrc:/home/andy3153/.gtkrc:/home/andy3153/.config/gtkrc
HOME=/home/andy3153
KDE_APPLICATIONS_AS_SCOPE=1
KDE_FULL_SESSION=true
KDE_SESSION_UID=3153
KDE_SESSION_VERSION=5
KONSOLE_DBUS_SERVICE=:1.32
KONSOLE_DBUS_SESSION=/Sessions/1
KONSOLE_VERSION=210803
LANG=en_US.UTF-8
LANGUAGE=
LC_COLLATE=ro_RO.UTF-8
LC_MEASUREMENT=ro_RO.UTF-8
LC_MONETARY=ro_RO.UTF-8
LC_NUMERIC=ro_RO.UTF-8
LC_TIME=ro_RO.UTF-8
LOGNAME=andy3153
MAIL=/var/spool/mail/andy3153
MMGT_CLEAR=1
MOTD_SHOWN=pam
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
OLDPWD=/home/andy3153
PAM_KWALLET5_LOGIN=/run/user/3153/kwallet5.socket
PATH=/home/andy3153/.local/bin:/home/andy3153/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/cuda/bin:/opt/cuda/nsight_compute:/opt/cuda/nsight_systems/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
PROFILEHOME=
PWD=/home/andy3153
QT_AUTO_SCREEN_SCALE_FACTOR=0
QT_QPA_PLATFORMTHEME=qt5ct
SESSION_MANAGER=local/sparkle:@/tmp/.ICE-unix/829,unix/sparkle:/tmp/.ICE-unix/829
SHELL=/bin/zsh
SHELL_SESSION_ID=21cbdf8701e641adb31e4840d3799866
SHLVL=1
SUDO_PROMPT=[sudo] password for %p: 
SYSTEMD_EXEC_PID=708
TERM=xterm-256color
TERMINAL=konsole
UBUNTU_MENUPROXY=1
USER=andy3153
VISUAL=nvim
WINDOWID=48234503
XAUTHORITY=/home/andy3153/.Xauthority
XCURSOR_SIZE=24
XCURSOR_THEME=McMojave-cursors
XDG_CACHE_HOME=/home/andy3153/.cache
XDG_CONFIG_DIRS=/home/andy3153/.config/kdedefaults:/etc/xdg
XDG_CONFIG_HOME=/home/andy3153/.config
XDG_CURRENT_DESKTOP=KDE
XDG_DATA_HOME=/home/andy3153/.local/share
XDG_RUNTIME_DIR=/run/user/3153
XDG_SEAT=seat0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=KDE
XDG_SESSION_ID=2
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
XDG_SESSION_TYPE=x11
XDG_VTNR=1
ZDOTDIR=/home/andy3153/.config/zsh
_=/usr/bin/printenv
PS1=%(?.%K{green}%F{black} √ %F{green}%K{black}$_charPowerlineArrowRight%f%k.%K{red}%F{black} × %F{red}%K{black}$_charPowerlineArrowRight%f%k)%K{black} %F{$_promptColorSSH}%n@%M $_promptGit%F{black}%K{$_promptColorUID}$_charPowerlineArrowRight%k%K{$_promptColorUID}%F{black} > %k%F{$_promptColorUID}$_charPowerlineArrowRight%f%k 
RPS1=%F{$_promptColorUID}$_charPowerlineArrowLeft%K{$_promptColorUID}%F{black} ? %(5~|%-2~/…/%2~|%4~)%F{black}%K{$_promptColorUID} $_charPowerlineArrowLeft %f%k%K{black}%F{white} ? %h %f%k
seth wrote:

And also what is the size (in point) of your default UI font?

systemsettings5 says it's 10pt. I haven't changed that either.

https://imgur.com/a/ptUc91n

Offline

#8 2021-11-11 16:51:22

seth
Member
Registered: 2012-09-03
Posts: 28,939

Re: [SOLVED]Messed up scaling with new Arch update

QT_AUTO_SCREEN_SCALE_FACTOR=0

So this is even disabled and I assume it's because

https://wiki.archlinux.org/title/HiDPI#KDE_Plasma wrote:

Plasma ignores the Qt scaling settings by default. To make Plasma respect the Qt settings, set PLASMA_USE_QT_SCALING to 1

So, speculation: Plasma assumes the srever at 96DPI, figures the real DPI is 140DPI and upscales everything by 146% - now that the server runs at 140DPI, plasma ends up upscaling the correctly scaled desktop.
=> Try

export QT_AUTO_SCREEN_SCALE_FACTOR=1
export PLASMA_USE_QT_SCALING=1

to the session and then allow the server to run at 140DPI.

Offline

#9 2021-11-11 17:35:39

Andy3153
Member
Registered: 2018-12-24
Posts: 62

Re: [SOLVED]Messed up scaling with new Arch update

seth wrote:

QT_AUTO_SCREEN_SCALE_FACTOR=0

So this is even disabled and I assume it's because

https://wiki.archlinux.org/title/HiDPI#KDE_Plasma wrote:

Plasma ignores the Qt scaling settings by default. To make Plasma respect the Qt settings, set PLASMA_USE_QT_SCALING to 1

So, speculation: Plasma assumes the srever at 96DPI, figures the real DPI is 140DPI and upscales everything by 146% - now that the server runs at 140DPI, plasma ends up upscaling the correctly scaled desktop.
=> Try

export QT_AUTO_SCREEN_SCALE_FACTOR=1
export PLASMA_USE_QT_SCALING=1

to the session and then allow the server to run at 140DPI.

So I added the export commands inside my .zshenv (might not be the place for them, most likely, wasn't sure where else to put them).
Then I changed in my /etc/sddm.conf.d/dpi.conf (the file that fixed everything) the DPI from 96 to 140:

/etc/sddm.conf.d/dpi.conf
---------------------------------------

[X11]
ServerArguments=-nolisten tcp -dpi 140

And it looked just the way it looked when the issue was present. I reverted to the original 96 when I saw it like that, and removed the export commands from my zshenv

Maybe my setup's weird. It's an Intel-Nvidia hybrid graphics laptop (Intel i7-11800H ; NVIDIA GeForce RTX 3060 Mobile / Max-Q) with no Intel drivers (letting it use the modesetting video driver) and the proprietary Nvidia drivers. Running games using PRIME render offloading (prime-run), but that shouldn't matter all that much since it's using the iGPU to actually show stuff on the screen. It's also a high refresh rate 1080p display

Last edited by Andy3153 (2021-11-11 17:36:42)

Offline

#10 2021-11-11 20:13:14

seth
Member
Registered: 2012-09-03
Posts: 28,939

Re: [SOLVED]Messed up scaling with new Arch update

might not be the place for them

No.

most likely

Very most.

wasn't sure where else to put them

https://wiki.archlinux.org/title/Environment_variables
https://wiki.archlinux.org/title/KDE#Autostart (~/.config/plasma-workspace/env/)

Not sure about SDDM atm but you can try eg. adding /etc/profile.d/unfuck_hidpi.sh

Offline

#11 2021-11-11 20:32:45

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 26,718
Website

Re: [SOLVED]Messed up scaling with new Arch update

Andy3153 wrote:

... but why was it changed if it broke for some people? Did it break for everyone?

You've got this backwards.  It was previously broken for most people ... for a long time.  It was finally fixed.

But anyone who has customized their fonts, panel sizes, etc, in order to compensate for the "brokenness" is now finding that those compensations are actually ugly when the original brokenness is gone.

Theoretically, you could lie to Xorg about your screen size in the opposite direction so that you'd be able to compensate for your compensations and get back to what it used to look like.  But this would be pretty silly.  Just adjust your fonts, sizes, or other gui configs to suit your tastes now that the old underlying problem is fixed.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#12 2021-11-11 20:37:33

seth
Member
Registered: 2012-09-03
Posts: 28,939

Re: [SOLVED]Messed up scaling with new Arch update

I actually start to suspect that Plasma is lying by default on behalf of the user… doesn't change much about the situation, but the wider impact has driven a reversion of the patch, so w/ the next X11 server release, everybody aligning to the correct DPI will have to establish them locally w/ the session startup *facepalmemoji*

Offline

#13 2021-11-12 04:47:06

flylightning
Member
Registered: 2021-11-12
Posts: 1

Re: [SOLVED]Messed up scaling with new Arch update

Trilby wrote:
Andy3153 wrote:

... but why was it changed if it broke for some people? Did it break for everyone?

You've got this backwards.  It was previously broken for most people ... for a long time.  It was finally fixed.

But anyone who has customized their fonts, panel sizes, etc, in order to compensate for the "brokenness" is now finding that those compensations are actually ugly when the original brokenness is gone.

Theoretically, you could lie to Xorg about your screen size in the opposite direction so that you'd be able to compensate for your compensations and get back to what it used to look like.  But this would be pretty silly.  Just adjust your fonts, sizes, or other gui configs to suit your tastes now that the old underlying problem is fixed.

It is painful to configure gui with the new true dpi. I need to change gtk3 scale, change gtk3 font scale, change xft dpi, use oomox to scale gtk2 correctly, change font size for individual softwares. But I still don't know how to change icon scale and how to change qt scale when using qt5-styleplugins. That is just too much work and I gave up midway. When using fake 96 dpi I live a happy life without need to change any defaults. So I prefer to use `xrandr --dpi 96` and take the blue pill.

Offline

#14 2021-11-12 07:24:16

seth
Member
Registered: 2012-09-03
Posts: 28,939

Re: [SOLVED]Messed up scaling with new Arch update

https://wiki.archlinux.org/title/HiDPI#Qt_5

without need to change any defaults

KDE?
Unless your DPI is miscalculated or some DE tries to be extra-smart or you've configured oversized fonts (12+ pt), there's no need to change any defaults.

I actually tried to (explicitly) set a 200 DPI on a 96 DPI output (on an 1.20 server) and gtk2 & Qt5 would align (at least) the font to that (my qt5 style virtuality is explicitly DPI aware) and gtk3 was utterly unimpressed and would use the physical DPI.
Only when also setting Xft.dpi I would receive a response from gtk3 and that value alone could control and override most things (ie. setting it to 96 got me a 96 DPI font - which would be too small on an actual 200 dpi output.

Offline

#15 2021-11-12 21:13:23

Andy3153
Member
Registered: 2018-12-24
Posts: 62

Re: [SOLVED]Messed up scaling with new Arch update

seth wrote:

might not be the place for them

No.

most likely

Very most.

wasn't sure where else to put them

https://wiki.archlinux.org/title/Environment_variables
https://wiki.archlinux.org/title/KDE#Autostart (~/.config/plasma-workspace/env/)

Not sure about SDDM atm but you can try eg. adding /etc/profile.d/unfuck_hidpi.sh


Neither of these worked. Tried /etc/profile, /etc/environment, the /etc/profile.d/unfuck_hidpi.sh script, and the ~/.config/plasma-workspace/env/ folder. None of these worked.

In every single case, PLASMA_USE_QT_SCALING was getting set as 1, but QT_AUTO_SCREEN_SCALE_FACTOR always kept being 0

Offline

#16 2021-11-12 21:16:30

Andy3153
Member
Registered: 2018-12-24
Posts: 62

Re: [SOLVED]Messed up scaling with new Arch update

Trilby wrote:
Andy3153 wrote:

... but why was it changed if it broke for some people? Did it break for everyone?

You've got this backwards.  It was previously broken for most people ... for a long time.  It was finally fixed.

But anyone who has customized their fonts, panel sizes, etc, in order to compensate for the "brokenness" is now finding that those compensations are actually ugly when the original brokenness is gone.

Theoretically, you could lie to Xorg about your screen size in the opposite direction so that you'd be able to compensate for your compensations and get back to what it used to look like.  But this would be pretty silly.  Just adjust your fonts, sizes, or other gui configs to suit your tastes now that the old underlying problem is fixed.


That's the thing. I haven't changed anything to acomodate for any change, not on this installation and not on this laptop. This installation is from around the end of July, I just installed it, didn't change anything and it worked well
I did have another laptop with an older installation where an update did something and I didn't bother to look for a solution and I just changed the font sizes, but not on this one.

Offline

#17 2021-11-12 21:35:03

seth
Member
Registered: 2012-09-03
Posts: 28,939

Re: [SOLVED]Messed up scaling with new Arch update

Andy3153 wrote:

In every single case, PLASMA_USE_QT_SCALING was getting set as 1, but QT_AUTO_SCREEN_SCALE_FACTOR always kept being 0

It's more likely being reset by plasma … *sigh*
If you

export QT_AUTO_SCREEN_SCALE_FACTOR=1 konsole

does the new konsole still (again) have it at 0?

Offline

#18 2021-11-12 21:40:54

Andy3153
Member
Registered: 2018-12-24
Posts: 62

Re: [SOLVED]Messed up scaling with new Arch update

seth wrote:

If you

export QT_AUTO_SCREEN_SCALE_FACTOR=1 konsole

does the new konsole still (again) have it at 0?

Nope. It actually sets it

Offline

#19 2021-11-12 21:49:54

seth
Member
Registered: 2012-09-03
Posts: 28,939

Re: [SOLVED]Messed up scaling with new Arch update

1. Does that have benficial impact on the new konsole window
2. Means plasma just steamrolls over this somewhen after the initial scripts are done, but it's not set in some library code.

Offline

#20 2021-11-19 19:55:15

Andy3153
Member
Registered: 2018-12-24
Posts: 62

Re: [SOLVED]Messed up scaling with new Arch update

seth wrote:

1. Does that have benficial impact on the new konsole window
2. Means plasma just steamrolls over this somewhen after the initial scripts are done, but it's not set in some library code.

I'm back now
And well I didn't look for any difference only in that window and I didn't see any either, so I don't know what to say

Offline

Board footer

Powered by FluxBB