Hacker News Reader

Comment by jagrsw | Hacker News Reader

Having two monitors with different DPI or physical size. Wayland supports different scaling per monitor, so your windows will look thesameish in terms of physical or pixel size (depending on your wishes) when moving them across monitors :).

View on HN

There isn't really a reason for this to not be done on Xorg too, aside from having the window manager keep track of per-monitor scaling information (note that scaling, physical size and DPI do not have to be tied - someone may want to use a big scale for a low DPI monitor because they have it across the room for example, what really matters is a per-monitor scaling factor - DPI can be used to set up some sane defaults but this should be overridable) and pass it to applications to scale themselves with a fallback if the application doesn't support scaling (be it client-side composition or server-side composition, though the latter will also need merging Keith Packard's patch that implements composition-based server side window scaling)... and someone to specify the messages/events involved.

But really almost all the tech exists (aside from server side scaling, but this can be ignored for an initial implementation) and toolkits (or at least Qt and perhaps Gtk) should already support this as Windows scaling works in a similar way, it is largely getting a bunch of different projects to play nice together.

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.

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 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.

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.

I've been out of the X vs Wayland discussion for ages, but have been on Gnome / Wayland on my work laptop for the last 2 years and wouldn't say that this use case is perfect or even great (though... it gets the job done). Guess your comment means it's even worse on X.

My work laptop is 4k 13" while my second monitor is 1440p 27". I had to enable some gnome custom scaling flag to unlock fractional custom scaling (as you probably also had to do) - not because I want to run my laptop at e.g. 175%, but because setting the laptop scaling to 200% without fractional scaling turned on would mess up all scaling on the external display too (many elements also 200% etc).

So with fractional scaling on, laptop at 200% scaling and external monitor at default 100% everything does work mostly right... except for all the programs that didn't get the memo and seem to scale properly but show up all blurred. I know it's a big Electron issue (so affects Slack, Chrome and VSCode... my 3 most-used programs) - unsure if it's a problem with other stuff.

But all in all has been kind of annoying.

I know they are working on fixes from the Electron angle but last I checked none of it was very stable.

That's cool but I don't know if you noticed many more problems it will cause.

Gaming can crash the session so I doubt that is a worthy tradeoff.

Reply on news.ycombinator.com