KDE vs Xresources

gcb · 2026-10-20 16:18:08

After the 6.8.0 kde/plasma update, now opening xterm gives me a blank slate one.

nothing in my xrdb until I manually load it up.

I was using kde+wayland since forever and never had to do this manually. Anyone know if they removed anything that was loading this automatically? it worked very well and I would like to see what it was to put it in place again

gcb · 2026-10-20 16:19:33

I just noticed Xwayland is now also "dumb" about my resolution. When the mouse cursor enters xterm it is reduced to a tiny tiny tiny one.

seth · 2026-10-20 18:28:13

xdpyinfo | grep reso
xrandr -q
xrdb -q | grep -i dpi
xrandr --dpi 200 # does this help?

Does your ~/.Xresources set Xft.dpi ?

Did/do you set the randr resolution in some startup script?
Might fall into the https://bbs.archlinux.org/viewtopic.php?id=315215 category or someone upstream overzealously purged too much of the "legacy" X11 code…

https://www.google.com/search?q=xresour … gs.kde.org has some hits but bugs.kde.org remains 403 here.

gcb · 2026-10-20 20:04:44

no dpi nor include hacks on my resource files. They just configure colors and fonts, in a very application specific way.

Your search showed some interesting bugs, like https://bugs.kde.org/show_bug.cgi?id=422548

But in KDE infinite wisdom, i'm blocked from reading them because they have random/bogus IP filters:

> Forbidden
> You don't have permission to access this resource.

sigh.

seth · 2026-10-20 20:23:56

As mentioned, same here (and there's https://bbs.archlinux.org/viewtopic.php?id=315192 )
But wget still works, so

Description Nate Graham 2020-06-06 19:44:50 UTC
OpenSUSE Tumbleweed with Qt 5.15 and all KDE software built from today's git master.
STEPS TO REPRODUCE
1. Set scale factor to 200%
2. Reboot
OBSERVED RESULT
Default 24px cursor is incredibly tiny and hard to find. You need to manually set it to 48px in the cursor KCM to make it the right size. And if you prefer a larger cursor (as I do) you're out of luck.
EXPECTED RESULT
The cursor size automatically scales with the systemwide scale factor. So for example a 24px cursor would get drawn at 48px when using a 200% scale factor. A 48px cursor would get drawn at 96px. And so on.
Comment 1 Nate Graham 2020-06-06 21:46:28 UTC
X11 is affected; Wayland is not.
Comment 2 phrxmd 2020-06-14 09:18:27 UTC
There is an underlying X issue here. You can see this from how cursor scaling depends on the window the cursor is over. E.g. if you set cursor size to 48px in the cursor KCM, the cursor still reverts back to tiny when you hover over an Xterm. Other applications where I'm observing this is the Brave browser where I'm now typing this, or the SoftMaker office package.
This is on OpenSUSE Tumbleweed with Qt 5.15, Plasma 5.19, Frameworks 5.70, Thinkpad Yoga X1 2560x1440 screen, scale factor set to 200%, cursor size set to 48px in the cursor KCM. Xft.dpi is set to 192 in .Xresources, and "xrdb -query all" reports Xcursor.size 48 (as set by the cursor KCM?).
Comment 3 Nate Graham 2020-07-07 19:47:36 UTC
*** Bug 423934 has been marked as a duplicate of this bug. ***
Comment 4 Vlad Zahorodnii 2020-07-30 08:15:26 UTC
The problem is that kwin ignores the scale factor on X11. Not sure how we can fix this bug.
Comment 5 Nate Graham 2020-07-30 12:55:52 UTC
Unhelpful comment: by making it respect the scale factor on X11! I'm here all week, folks...
Comment 6 Vlad Zahorodnii 2020-07-30 12:58:44 UTC
> Unhelpful comment: by making it respect the scale factor on X11!
We will break basically every application if we start honoring the scale factor.
Comment 7 Nate Graham 2020-07-30 13:00:53 UTC
Would it be possible to teach KWin how to respect the scale factor for things only under our control where we can make sure it doesn't break, then? E.g. the cursor, window decorations, the window decoration pop-up menu, etc.
Comment 8 Zamundaaa 2024-04-25 14:10:06 UTC
I think an inconsistent cursor size would be worse than just having the same wrong one always. It's not really fixable, and it works correctly on Wayland, so I'm closing this

Unrelated, and btw. also wrong.
KWin has nothing to do w/ that but the DE could configure a different cursor (size) depending on the DPI (so the GUI says 24px, but you're at 192 dpi or 200% scale so you're actually configuring the 48px version that will then get picked up by clients accordingly)
But that's also no longer relevant.

gcb · Yesterday 17:44:24

found something that points to sddm? https://github.com/sddm/sddm/issues/449

The dpi (and consequently the cursor size) issue was kde's fault indeed! They changed the default for auto-scalling X11 apps in the display window. When I simply moved the radio button selected for this in settings>display, it went back like it was before 6.8

Now xrdb have dpi set correctly by KDE/xwayland. Still unsure "how".

Last edited by gcb (Yesterday 17:45:24)

gcb · Yesterday 17:55:09

Ooops. I screwed up my greps before. I see now that this is probably handled by /etc/X11/xinitrc --which seems obvious in retrospect

So the issue is likely xwayland (or how kde spawn xwayland) not executing those?

edit: NOPE! it is not that! lol. because xinitrc also would have started xclock, xterm and twm lol. Did i just woke up from a dream and i'm in 1967?

Last edited by gcb (Yesterday 17:57:31)

seth · Yesterday 20:23:06

found something that points to sddm? https://github.com/sddm/sddm/issues/449

SDDM would at most run /usr/share/sddm/scripts/Xsetup but SDDM doesn't start an X11 session.

Xwayland doesn't run any session setup script (just like Xorg would not) so you'd expect the invoking process (plasma/kwin) to do that.
And no, xinitrc has never been part of that, it's used by xinit/startx and XDM

https://gitlab.gnome.org/GNOME/mutter/-/work_items/677
xterm specifically will parse ~/.Xdefaults
Otherwise you'll either have to wrap Xwayland or run and keep a persistent X11 process (like xclock ) and load the resources once - and file a bug at KDE once they allow that again…

gcb · Today 18:17:48

This is driving me crazy

I am 100% sure something in KDE was handling this. Now I've added a .desktop file to call xrdb... but i'm sure when they finally add xwayland session clean up soon it will cause me troubles lol
(that discussion about this on the linked bug is scary... they are making the problem infinitely more complex than it should! hope they don't go any of the crazy routes they discussed there.)

The fact xterm still loads Xdefault might actually be a saving grace. Maybe I will just symlink those two files. Thanks for pointing that out!

Last edited by gcb (Today 18:23:06)

seth · Today 20:15:44

The linked mutter bug is from 2019 - xwayland is run dynamically and auto-terminates shortly after the last client disconnected.
(Sorry I maybe should have pointed out that this was just to illustrate the inherent problem and how we arrive here and why just loading xrdb once w/ any session start will typically not solve the problem)

From what I can tell r/n your main/only issue is the HiDPI one (font and cursor in xterm too tiny)?
There used to be a setting for that, https://wiki.archlinux.org/title/HiDPI#Xwayland_2

Arch Linux

#1 2026-10-20 16:18:08

KDE vs Xresources

#2 2026-10-20 16:19:33

Re: KDE vs Xresources

#3 2026-10-20 18:28:13

Re: KDE vs Xresources

#4 2026-10-20 20:04:44

Re: KDE vs Xresources

#5 2026-10-20 20:23:56

Re: KDE vs Xresources

#6 Yesterday 17:44:24

Re: KDE vs Xresources

#7 Yesterday 17:55:09

Re: KDE vs Xresources

#8 Yesterday 20:23:06

Re: KDE vs Xresources

#9 Today 18:17:48

Re: KDE vs Xresources

#10 Today 20:15:44

Re: KDE vs Xresources

Board footer