Remix.run Logo
jhasse 5 hours ago

I'm using KDE with Wayland and 2 non-standard DPI monitors (one at 100% the other at 150% scale). No workarounds needed, nothing is blurry. I think your experience comes from GNOME which lacks behind in this regard.

simoncion 3 hours ago | parent | next [-]

FWIW, I can do the same with KDE on Xorg with Gentoo Linux.

Since the introduction of the XSETTINGS protocol in like 2003 or 2005 or so to provide a common cross-toolkit mechanism to communicate system settings, the absence of "non-integer" scaling support has always been the fault of the GUI toolkits.

> I think your experience comes from GNOME which lacks behind in this regard.

When doesn't GNOME lag behind? Honestly, most of Wayland's problems have been because a project that expects protocol implementers and extenders to cooperate in order to make the project work set those expectations while knowing that GNOME was going to be one of those parties whose cooperation was required.

mixmastamyk 5 hours ago | parent | prev [-]

Mint/cinnamon here at 150%, X11, not blurry. It’s FUD.

vladvasiliu 4 hours ago | parent [-]

The issue with X11 is that it's not dynamic. Think using a laptop, which you sometimes connect to a screen on which you require a different scale. X11 won't handle different scales, and it also won't switch from one to the other without restarting it.

simoncion 3 hours ago | parent [-]

> The issue with X11 is that it's not dynamic.

No, it is. Maybe you're using an ancient (or misconfigured) Xorg? Or maybe you've never used a GTK program? One prereq is that you have a daemon running that speaks the ~20 year old XSETTINGS protocol (such as 'xsettingsd'). Another prereq is that you have a DE and GUI toolkit new enough to know how to react to scaling changes. [0]

Also, for some damn reason, QT and FLTK programs need to be restarted in order to render with the new screen scaling ratio, but GTK programs pick up the changes immediately. Based on my investigation, this is a deficiency in how QT and FLTK react to the information they're being provided with.

At least on my system, the KDE settings dialog that lets you adjust screen scaling only exposes a single slider that applies to the entire screen. However, I've bothered to look at (and play with) what's actually going on under the hood, and the underlying systems totally expose per-display scaling factors... but for some reason the KDE control widget doesn't bother to let you use them. Go figure.

[0] I don't know where the cutoff point is, but I know folks have reported to me that their Debian-delivered Xorg installs totally failed to do "non-integer" scaling (dynamic or otherwise), but I've been able to do this on my Gentoo Linux machines for quite some time.

vladvasiliu an hour ago | parent [-]

I use whatever package is shipped by arch, so I think I'm fairly up to date.

I did look a bit into this at one point, but I've found that it's mostly QT apps which work fine with different scaling (telegram comes to mind). GTK apps never did, but I admit I never went too deep in the rabbit hole. Didn't know there was supposed to be some kind of daemon handling this. I do run xsettingsd, but for unrelated reasons. I'll have a look if it can update things.

In any case, except for work, I always used everything at 100% and just scaled the text as needed, which worked well enough.

> I've bothered to look at (and play with) what's actually going on under the hood, and the underlying systems totally expose per-display scaling factors...

Would you care to go into some details? What systems are those and how do you notify them there's been a change?