Hacker News Reader

Comment by jagrsw | Hacker News Reader

I think Qt supports it in some quirky way. It supports this DPI notation of something like

QT_DPI="192;128"

via envvars. But it only means that when moving window to another monitor the window will get suddenly re-scaled/re-sized, instead of being smoothly drawn using different scaling factor.

View on HN

Well, yes, this is basically all what applications can do by themselves without support from the rest of the stack. It isn't impossible but it will be limited to application/library-specific hacks and those have a limited view of the system anyway. Ideally you want support from the environment itself and applications only be responsible for scaling themselves properly.

The window manager is at the best position to support something like this since it handles window placement. It is possible to have a separate program that can keep track of window placement and support the relevant events too (for window managers that wont support this) but it can be tricky to get it work smoothly.

The sudden scale/resize is something that can't really be avoided without support from the compositor (be it the window manager, a separate compositor or server-side composition), assuming there is one of course (this should work without a compositor too, you'd just wont get the scaled fallback unless the server-side scaling patch is also added to Xorg). Again, can be done and the tech is there, it just needs wiring all these things up.

The problem with environment variables is that it doesn't support dynamically adding and removing monitors and changing the scale factor of an existing monitor.

Also personally I think integer (if any) coordinate scaling, and fractional font-only scaling (or fractional blurry server-side scaling) is the only way to support fractional DPI scaling without breaking the fundamental assumption that integer-aligned pixel rectangles don't overlap or partially cover pixels. Qt's fractional coordinate scaling breaks much of current theming and app painting algorithms.

The Qt QPA for Wayland supports this properly and natively since ~2017 or earlier, and will render one single app at multiple DPIs around screen boundaries.

"One app window, two monitors, two DPIs" https://kde.org/announcements/plasma/5/5.11.0/#wayland

Yes, but the discussion here is how that could be done with Xorg, not Wayland. My point is that the tech is there and at least Qt already has code for it, but it just needs all the relevant projects to work together. Or more accurately, someone to make all the necessary patches for all the affected projects and have these patches be accepted :-P.

I don't plan on getting one since i find even 1440p/27" too much for my taste (i only got it because it was the only high refresh rate monitor with a flat VA panel i could find available when i decided to get a new monitor) but if i ever have to get a hidpi monitor (e.g. someone finally released an OLED monitor but does the annoying thing and only makes it available in a single configuration that happens to be 4K because bigger numbers are better, all other concerns be damned), i'll try to go through everything to get it working on my PC (assuming noone else does it before).

I doubt this will get done on Xorg any time soon, there is very little incentive for anyone to do it when it's already working much better on Wayland. The problem is in finding someone who will do it, it's not really a problem to figure out how it could be done because we already know that: just copy the Wayland API back into X. A good way to start would probably be to get scaling working in XWayland applications and then backport from there; amazingly, we're finally at the point where Xorg is playing catch up to Wayland in terms of features. I can't understate how huge that achievement is for the Linux display stack.

At this rate is it possible that x.org will just absorb the benefits of wayland while having graphical issues and less safety?

I don't think so, the X.org server would likely have to be rewritten entirely to get some of the improvements of Wayland. And at that point you might as well use Wayland. People have written alternate X servers before but I've never seen one that was totally feature compatible with X.org.

I am suggesting that wayland may not reach critical mass because of backporting these features, and wayland lacking a lot of functionality would prevent me from using it, until its reach partiality or enough functionality. I had mostly a great time with it on GNOME and a tablet interface, but I missed widgets and some functionalities.

In terms of developer velocity I think it has already reached critical mass. I can't comment on any particular missing features in GNOME, to me it is probably more likely that a GNOME contributor is working on getting those features ported over to Wayland than somebody working on backporting things to X.

That's great, I'll switch when its not a skeletonized version of the functionality I use now, I hope there is an easy way to import global hotkeys in my current programs, and have widgets or GUI support. I tried using ctrl and up as a hotkey in the compositor for instance and it never worked in dbus when I tried last week.

I just mentioned GNOME because I actually really dislike it, and was forced to use it for good tablet support with wayland, they broke those plugins I used.

Reply on news.ycombinator.com