What sets Xresource Xft.dpi: 96 on konsole start? (old issue, not new)
All, I've watched this problem for years and am finally chasing it down a little further. When KDE3 starts, the Xft.dpi property is unset. So for example opening an xterm (not konsole) displays in the desktop native dpi (on my laptop that is 103). However, when konsole is started, something changes the Xft.dpi property to 96 (which was a very common dpi setting in the CRT monitor days) The problem this causes is when a new xterm is opened after konsole has been started, the xterm window, fonts, etc are scaled nearly 8% smaller by the dpi changee. Manually resetting Xft.dpi using xrdb -merge fixes the issue, e.g. $ xrdb -merge Xft.dpi: 103 (ctrl+d) Now starting a new xterm is fine. Any idea where in konsole startup are Xresources modified? -- David C. Rankin, J.D.,P.E.
David C. Rankin composed on 2022-08-03 15:37 (UTC-0500):
I've watched this problem for years and am finally chasing it down a little further. When KDE3 starts, the Xft.dpi property is unset. So for example opening an xterm (not konsole) displays in the desktop native dpi (on my laptop that is 103). However, when konsole is started, something changes the Xft.dpi property to 96 (which was a very common dpi setting in the CRT monitor days)
The problem this causes is when a new xterm is opened after konsole has been started, the xterm window, fonts, etc are scaled nearly 8% smaller by the dpi changee.
Manually resetting Xft.dpi using xrdb -merge fixes the issue, e.g.
$ xrdb -merge Xft.dpi: 103 (ctrl+d)
Now starting a new xterm is fine. Any idea where in konsole startup are Xresources modified?
Is your described behavior on TW or Leap? That's not how it works here. In Xterm: # pinxi -GSaz --vs pinxi 3.3.20-02 (2022-07-29) System: Kernel: 5.14.21-150400.24.11-default arch: x86_64 bits: 64 compiler: gcc v: 7.5.0 parameters: root=LABEL=<filter> ipv6.disable=1 net.ifnames=0 noresume mitigations=auto consoleblank=0 vga=791 video=1440x900@60 5 Desktop: KDE v: 3.5.10 tk: Qt v: 3.3.8c info: kicker wm: kwin vt: 7 dm: 1: KDM 2: XDM Distro: openSUSE Leap 15.4 Graphics: Device-1: AMD RV620 PRO [Radeon HD 3470] vendor: Dell C120D driver: radeon v: kernel arch: TeraScale process: TSMC 55-65nm built: 2005-13 pcie: gen: 1 speed: 2.5 GT/s lanes: 16 ports: active: DP-1,DP-2 empty: none bus-ID: 01:00.0 chip-ID: 1002:95c0 class-ID: 0300 Display: x11 server: X.Org v: 1.20.3 driver: X: loaded: modesetting unloaded: fbdev,vesa gpu: radeon display-ID: :0 screens: 1 Screen-1: 0 s-res: 4240x1440 s-dpi: 120 s-size: 897x304mm (35.31x11.97") s-diag: 947mm (37.29") Monitor-1: DP-1 pos: primary,left model: Acer K272HUL serial: <filter> built: 2018 res: 2560x1440 hz: 60 dpi: 109 gamma: 1.2 size: 598x336mm (23.54x13.23") diag: 686mm (27") ratio: 16:9 modes: max: 2560x1440 min: 720x400 Monitor-2: DP-2 pos: right model: Lenovo L2251x Wide serial: <filter> built: 2011 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2 size: 474x296mm (18.66x11.65") diag: 559mm (22") ratio: 16:10 modes: max: 1680x1050 min: 720x400 OpenGL: renderer: AMD RV620 (DRM 2.50.0 / 5.14.21-150400.24.11-default LLVM 11.0.1) v: 3.3 Mesa 21.2.4 compat-v: 3.0 direct render: Yes # ps -A | grep onsol # xrdb -query | grep dpi # konsole & # xrdb -query | grep dpi # xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r Screen 0: minimum 320 x 200, current 4240 x 1440, maximum 8192 x 8192 DP-2 connected 1680x1050+2560+0 (normal left inverted right x axis y axis) 474mm x 296mm DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 2560x1440 59.95*+ 74.92 1680x1050 59.97*+ 74.89 59.95 59.88 # xdpyinfo | egrep 'dimen|ution' dimensions: 4240x1440 pixels (897x304 millimeters) resolution: 120x120 dots per inch # grep -v ^\# /etc/X11/xinit/xinitrc.d/setup | grep xrandr xrandr --dpi 120 # If KControl > Fonts is used to force DPI to 120, then # grep 120 ~/.kde/share/config/kcmfonts forceFontDPI=120 # If you wish a particular Xft.dpi value, KDE3 sessions will pick it up from ~/.Xresources if set there. Values there are not limited by GUI. In Mageia and Fedora (historically at least; I've not checked lately), then: # grep dpi /etc/X11/Xresources Xft.dpi: 96 # Upstream GTK as of 3.17.x forces 96 into Xft.dpi if not otherwise set. In openSUSE bug 1022830 this was reverted, at least for IceWM, KDE3, TDE and Plasma users. Debians, Mageia & Fedora maintain upstream's rudeness. Other distros, and other openSUSE DEs, I have no idea about. cf. https://www.linuxquestions.org/questions/linux-software-2/xft-dpi-what-tool-... https://bugzilla.opensuse.org/show_bug.cgi?id=1022830 https://bugs.freedesktop.org/show_bug.cgi?id=98909 https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 https://bugzilla.gnome.org/show_bug.cgi?id=757142 https://bugs.kde.org/show_bug.cgi?id=367499 https://bugs.mageia.org/show_bug.cgi?id=21201 -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 8/3/22 19:30, Felix Miata wrote:
Is your described behavior on TW or Leap? That's not how it works here.
This is Leap 15.4
In Xterm: <snip>
Leap only has inxi, so: # inxi -GSaz System: Kernel: 5.14.21-150400.24.11-default x86_64 bits: 64 compiler: gcc v: 7.5.0 parameters: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150400.24.11-default root=UUID=082f3bf4-265b-4b6f-b5b5-cca79ba230c0 splash=silent preempt=full mitigations=auto quiet security=apparmor Desktop: KDE 3 tk: Qt 4.8.7 info: kicker wm: kwin vt: 7 dm: KDM Distro: openSUSE Leap 15.4 Graphics: Device-1: NVIDIA GF104GLM [Quadro 3000M] vendor: Hewlett-Packard driver: nvidia v: 390.154 alternate: nouveau,nvidia_drm bus-ID: 01:00.0 chip-ID: 10de:0e3a class-ID: 0300 Device-2: Sunplus Innovation HP HD Webcam [Fixed] type: USB driver: uvcvideo bus-ID: 2-1.4:3 chip-ID: 1bcf:2805 class-ID: 0e02 Display: x11 server: X.Org 1.20.3 driver: loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa alternate: nv display-ID: :0 screens: 1 Screen-1: 0 s-res: 1600x900 s-dpi: 106 s-size: 383x222mm (15.1x8.7") s-diag: 443mm (17.4") Monitor-1: LVDS-0 res: 1600x900 hz: 60 dpi: 106 size: 382x215mm (15.0x8.5") diag: 438mm (17.3") OpenGL: renderer: Quadro 3000M/PCIe/SSE2 v: 4.6.0 NVIDIA 390.154 direct render: Yes
# ps -A | grep onsol 5575 ? 00:00:18 konsole
# xrdb -query | grep dpi Xft.dpi: 103
(I set it -- it's not set in the default ~/.Xresources -- though I can add it easy enough)
# konsole &
OH no, no, I got this, Xft.dpi: is 96 after konsole is started, I then manually set it to 103.
snip
If you wish a particular Xft.dpi value, KDE3 sessions will pick it up from ~/.Xresources if set there. Values there are not limited by GUI.
Yes, yes, I can set it there no problem, or set it with xrdb -merge, but I was trying to figure out what needs to be patched to change the behavior.
In Mageia and Fedora (historically at least; I've not checked lately), then: # grep dpi /etc/X11/Xresources Xft.dpi: 96 #
Upstream GTK as of 3.17.x forces 96 into Xft.dpi if not otherwise set. In openSUSE bug 1022830 this was reverted, at least for IceWM, KDE3, TDE and Plasma users. Debians, Mageia & Fedora maintain upstream's rudeness. Other distros, and other openSUSE DEs, I have no idea about.
Ah, hah -- this may be Gtk3 related, but it is more a curiosity than anything else. This also specifically impacts Gtk apps (both 2 and 3). If I start gtk apps *before* I start console and Xft.dpi: is set to 96, the Gtk menu fonts, etc. will all appear 1 pt too big. AFter whatever forces to 96, the Gtk apps start with the correct font size -- but it screw xterm up. I suspect this is a Gtk FU or kludge that was put in place to make Gtk fonts look right that hoses xterms started afterwards. Only bummer is that opens up a whole additional set of sources where the problem may be hiding.... This is "as time permits" stuff. KDE3 on 15.4 is rocking along brilliantly. Thanks for providing the additional background. That saves days if not weeks ferreting that info out on my own. -- David C. Rankin, J.D.,P.E.
On 8/5/22 02:12, David C. Rankin wrote:
Ah, hah -- this may be Gtk3 related, but it is more a curiosity than anything else. This also specifically impacts Gtk apps (both 2 and 3). If I start gtk apps *before* I start console and Xft.dpi: is set to 96, the Gtk menu fonts, etc. will all appear 1 pt too big. AFter whatever forces to 96, the Gtk apps start with the correct font size -- but it screw xterm up.
I suspect this is a Gtk FU or kludge that was put in place to make Gtk fonts look right that hoses xterms started afterwards. Only bummer is that opens up a whole additional set of sources where the problem may be hiding....
Damn! It's not konsole per-se that sets Xft.dpi, but it occurs when konsole is launched with a bash script that makes dcop calls to restore the 9 or so console tabs I normally have open. (attached). Why in the heck would making dcop calls launching konsole sessions set dpi? (1) I booted cold to kde and immediately opened xterm. Xft.dpi is *NOT* set, but is at the screen native 103 and the xterm size and font is fine. (2) I opened a single konsole session and checked and Xft.dpi is *NOT* set. (3) opened konqueror and kate and Xft.dpi is *NOT* set. (4) restored my konsole sessions with the dcop script Xft.dpi *IS* set at 96?? WTF? Nothing in that script touches dpi. (5) xrdb -merge and Xft.dpi: 103 restores the dpi to the native value when Xft.dpi is unset. (I compared current/new xterm instances after resetting to 103 and they are identical pixel for pixel in size. So this is definitely a KDE3 thing related to dcop. It may be that dcop has some interface to Gtk that causes Gtk to set the dpi -- but that will have to be found in the source if it exists. DOES THE KDE3 SOURCE EXIST IN SEARCHABLE FORM (e.g. outside a bunch of .srpm files) somewhere on the net? Or do I just need to copy the srpms from the kde3 rpo?? (rsync? what's the best way to duplicate the 15.4 source?) -- David C. Rankin, J.D.,P.E.
participants (2)
-
David C. Rankin -
Felix Miata