Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among other things when it didn't work
Some relevant links for those curious about other people hitting into this:
https://www.foell.org/justin/simple-hidpi-monitor-scaling-wi...
Gnome team:
One of my desktops uses 2x 4k monitors, is that hidpi? X works fine... X also worked fine on an older setup with 4 monitors.
Also, I don't know Wayland internals, but I'm gonna assert without proof that any low level graphics interface is gonna involve a framebuffer at some point...
You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks that teams, specifically I've seen the canonical team pull this off, where they can "trick" xorg into displaying properly with some minor visual artifacting. The last time I tested this was with Ubuntu a few years ago, back when Wayland support was "experimental" and I had this exact sort of setup, and Wayland was easily able to pull this off 100% better in every way because it is not designed around this limitation.
The word "properly" here is quite subjective, though. I have a similar setup, combining monitors of different pixel sizes. It works properly with Xorg: When I move a window of size WxH pixels from one monitor to another, it remains a window of WxH pixels. A thin line of one pixel width remains so. A checkerboard pattern that tingles the monitor refresh rate remains so. This sounds like perfectly appropriate behavior, and anything else would be ridiculously inappropriate. I accept that this usage of "appropriateness" is subjective to a subset of people that includes me, but it may not be universal.
Whatever, this is such a thin point for Wayland: hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before. But hey! you can combine monitors of different pixel size as if they had the same pixel size! See, the thing transparently re-scales your windows using cheap-ass bilinear interpolation so that they get the exact same size in millimeters! Fancy, isn't it?
No. It's creepy.
Wayland has had working screenshots, screen recording, clipboard functionality for text and arbitrary mimetypes, etc. for years on wlroots, GNOME, and KWin. It also has ydotool, an xdotool alternative. For pure keyboard automation it also sports wtype.
Which apps don't support Wayland? The only ones on my machine that need XWayland are some video games and FLTK apps like Dillo (I have to test with xwininfo since it's normally impossible for me to notice if a program is using XWayland). All GTK/Qt apps work OOTB on Wayland as a first class citizen, especially since those toolkits nowadays receive more Wayland testing than X11 since barely any current distros still ship X in their default installations.
Which Wayland compositor/version and GUI toolkit/library gave you blurry bilinear filters?
In your example, I imagine everything would work just fine, but images will be physically bigger on the 70 DPI monitor because, well, the pixels are bigger. I'm guessing that Wayland adds a layer of indirection, resampling the framebuffer based on the DPI to preserve the same point size across displays with different pixel sizes.
I ascribe to "the end user is always right" philosophy, so, if you want that functionality, you should be able to have it. But I wonder how popular that desire is. It's far from universal.
Personally, I find resampled images to be so distracting and distasteful that it makes a computer hard to use for more than a few minutes. I hate fuzzy text, fuzzy windows, and fuzzy pixels. Any time I've been forced to use a device at something other than its native resolution, I've gotten preoccupied with "how can i fix this ugly crap" until I get native resolution working, and I'm sure I'm not alone.
It's cool that Wayland does that for you, because you want it, but consider that to others, it might be a bug, and not a feature. :)
Note that I am not talking about multiple displays, but rather a single display, but the user wants things to be bigger than they are by default.
I know this because have used all 3 major operating systems recently (MacOS, Windows 10 and Linux/Gnome) on plain-old 96-DPI monitors such that if there were any interpolation or scaling algorithm I would be able to see the effects.
On a monitor 1680 pixels wide, Gnome gives me a choice of the scaling factors 100%, 125%, 150%, 175% and 200%. On a monitor 1920 pixels wide, Windows 10 gives me a choice of the scaling factors 100%, 125%, 150% and 175%. Some apps are blurry as hell, but on both Windows and Gnome I was able to live my life using only those apps that don't have the blurriness problem, but then I am not forced to use old Windows apps provided or specified by my employer and don't need to share my screen (which I am told does not work yet on a pure-Wayland set-up like mine).
On Windows 10, I used Google Chrome, some apps such as Settings and Timer provided as part of the OS and VS Code. On Linux I used (and continue to use) Google Chrome, modern Gnome apps and Emacs. On Linux, I need to open Chrome with specific flags to get it to be non-blurry while the visual elements are a non-standard size, and I need an Emacs built from a git branch called feature/pgtk. Both apps have some bugs when used in this way, but the bugs are definitely live-with-able, and I expect the bugs to be fixed eventually.
"On a Wayland display server, each connected monitor will have a scale that depends on the DPI. A scale affects the scale clients draw surface contents when they are visible on said monitor."
So it seems like it actually modifies the drawing at the application level rather than rescaling it like an image.
>My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?”
>Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
xrandr --dpi 100/eDP-1The support of hidpi scaling is something Toolkits have to manage (on both Wayland and X11). On X11 all the necessary pitch information to do so is available via the xrandr extension.