This is the only actual, honest, problem that I've ever seen about X. Still, it does not seem a really fundamental problem, it must surely be solvable from within X? Do we really need a full-rewrite of X, unstable, with new bugs and less functionalities? (many of us don't use "desktop" applications and it will break screen capture tools, and other things that are dear to us like xwit, xdotool and the like). Just for that silly mixed-resolution screen problem? I have observed this problem, but to me is a minor, mostly irrelevant nuisance. Losing xwit would be a major problem.
The transition to Wayland is largely finished now. Electron added support last year and eventually the last of the electron apps will update and everything will be done other than nvidia proprietary driver support.
There are so many minor improvements from wayland that are less noticeable like the lack of screen tearing, the possibility of sandboxing apps.
Fedora has has it on by default for about 4 years now and its perfectly usable. I use it every day.
The problem is much more serious than you are explaining. While using X, on my main monitor, UI and text becomes so small I can not even read it or click the icons. I'm not talking about the window size, but the UI and text size. With wayland the app can switch from 200% scale to 100% scale as it crosses the window border. On X you must pick either 100% or 200% and stick with it on all monitors.
Can Wayland handle this? If not, what's it really solving?
Yes.
I really am curious what features you think wayland is lacking. I've been using wayland for years, both using Sway and Gnome, and the thing I've missed the most is xdotool, and perhaps there will be a standardization effort to replicate its functionality securely, but for now it's an understandable omission.
Maybe it's not fair to say that X is broken for mixed-DPI configurations, since I have managed to get it working with X, but it was quite unreliable, whereas on wayland it just works, save for some incompatible electron apps.
X gives you two options: set DPI per displays. The thing is, you cannot drag windows between displays, the app has destroy it, connect to another one and recreate it here. There's even no mechanism to detect multiple displays other that user setting up the DISPLAY env variable.
Or you can do, as the Xorg does: use multiple screens on a single display. Here, the limitation is, that all screens have to have same DPI.
Neither of those are acceptable for modern display server.
> it will break screen capture tools,
It is a good thing that they are broken, because what they do is snooping on windows that do not belong to them. Just like it is unacceptable to integrate user address book to your app by going through its internal files, it is unacceptable to screen grab by snooping windows of other apps. In both scenarios, your app must go through API, which puts the user in the control, whether the app is allowed to do that. Wayland enforces such protocol for screen grabbing and input handling; those app who do not bother... well, the train will leave the station without them.
> other things that are dear to us like xwit, xdotool and the like
Same as previous, but for input handling.
> Just for that silly mixed-resolution screen problem?
No, there are multiple problems. For another, surely you would like screen lock that doesn't flash your desktop on unlock?
> I have observed this problem, but to me is a minor, mostly irrelevant nuisance. Losing xwit would be a major problem.
See even here on HN, it is important for many. Just few days ago there was a discussion under article about i3 and how to drag it into hidpi world in 2021. On the other hand, the mainstream user doesn't even know why they would use xwit, even if they knew it exists.
Don't want to derail this discussion anymore, but this argument is nuts. If you are so concerned that programs that you run can spy on other programs that you run, how do you deal that the fact that all of these running programs have full read-write access to all files on your $HOME?
EDIT: I agree that being able to run selected programs inside a sandbox would be a good thing (maybe even all programs). But attacking the problem of visible display before that of hidden files seems ridiculous. Moreso if it cripples copy paste, screen capture, and similar basic stuff (which to me are just like unix pipes: ways to make programs work together!)
They don't necesarilly do; if you are running flatpak, chances are that they don't.
For example, there is a flatpak for MS Teams. For application like this, you want it to be able to share your screen, but it doesn't have any access to your $HOME (in this specific case, only to ~/Downloads).
More importantly, if you want to tight up your desktop, why do you criticize something that starts attacking it from one angle, that it is not 100% solution? It is not; others are working on the other angles, and then together it will be the 100% solution. In this case, Wayland is only one piece of puzzle, not the entire puzzle.
The limitation is not true. Yes, the core protocol gives you a single, global DPI value. However, who cares about the core protocol? You have XRandR, which gives you a per-screen DPI. Alternative, you could have a freedesktop standard/convention where the DPI is stored as a global property of the root window, in a array of values, one for each display, so that you can override them.
Problem solved! I am actually running Gtk+ slightly patched to support that... trouble is, most of the toolkit is hardcoded to assume a fixed display or even process-wide global DPI, or at least it was when I last looked at it. Dunno what they did for wayland.
I really don't understand why we need to throw away an entire 30 years of software development just because the current property for storing the DPI only has space for 1 value instead of 1 array of values, one per monitor. Just use a new property.
Not so fast!
Are you going to patch it to decade old binaries? How are you going to handle that Wordperfect from 1998? It certainly won't respect you new protocol.
How the compositors are supposed to handle that?
If you are not going to handle it, and just let it behave as it behaves today, you are still not achieving your goal of scaling all clients properly, and kind of throwing away that 30 years of development by making it unusable anyway.
You need to put in some type of kludge which is the reason this article exists in the first place (e.g. copy paste will work randomly).
And if the toolkit is linked dynamically, you are very lucky... Not to mention that a more realistic scenario is that you have to update a 20 year old toolkit to support multiple DPIs, in which case it is much easier if you just have to read the property from a different place rather than having to target a different display protocol entirely. You made the program vendors life easier at the cost of making yours harder...
Even window grabbing will work, albeit only with other Xwayland clients.
No reason your "classic" X11 compositor cannot scale and make any windows blurry, either. No changes required to the client code at all, but some are required to X11 itself, e.g. https://www.youtube.com/watch?v=BrK4c7iFJLs
The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. If you run Chrome, it can render itself properly for HiDPI; if you run Gimp (the Gtk2 one), it won't, it needs to be scaled, Meanwhile, the compositor is none the wiser, which is which, which needs to be scaled and which doesn't. So Xwayland lies to them all about real dpi, and upscales everything.
For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years ("it works in the current Ubuntu LTS, we are fine, no need to add anything").
Just make a new property, and make those DPI-aware clients set it!
You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it". This would be trivial to write in X11, but becomes again Mission Impossible in Wayland (you have to edit every display server -- Gnome's, KDE's, etc. -- in existence).
> For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years
Yes, exactly. But it is going to be much harder to make anyone support Wayland within the next 10 years, since it brings its own share of problems and because of "the devil you know". E.g. can Firefox already screen grab from Wayland these days? From non-Gnome Wayland? Will Zoom ever do it? And work with any Wayland display server other than Gnome's? It is a mess, and has been so for a decade already. And that is why we get this article.
That's the easy part.
> and make those DPI-aware clients set it!
That's the difficult part. You are welcome to try, though!
> You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it".
Yes, another hack to keep on piles on other hack. Why would anyone want nice, clean solution, when a hack does?
> E.g. can Firefox already screen grab from Wayland these days?
Firefox can do screen recording/screen sharing under Wayland these days. Hardware encoding for WebRTC is in the works; that's something they would not be able to efficiently do under X11 at all.
> Will Zoom ever do it?
That's the question for Zoom. If we kick them as Apple does, they will. If we lay down and keep piling hacks on top of other hacks, they won't see the point.
> And work with any Wayland display server other than Gnome's?
That's a question you have to ask the authors of any Wayland display server other than Gnome's.
> It is a mess, and has been so for a decade already. And that is why we get this article.
It is a mess, because some people are too hung up on their current ball of mud and cannot see further than their personal desktop. Then they write articles like this and try to drag down others to the level of their ball of mud.
I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, and creating a program to do this change for these toolkits externally without changing them at all is a "hack" (despite the fact users likely want to do this, as evidenced by Windows offering this setting); but on the other hand throwing everything away and changing everything to support an entirely new display server protocol with its on set of problems is ... a nice, clean solution?
What I see is another manifestation of the "backward compatibility is a hack" mentality. Well, this annoys me to no end, but what can I do.
Because if it was just setting a new property in a toolkit, we would not have this discussion now.
Ultimately, it is not just that; if it were, all clients would be Wayland native already as the toolkits have had Wayland backends for years.
As for the "Meanwhile" part, again, how is that better with a new display stack? Unless the point here is that it will be better to just break all those (DPI-aware) clients unconditionally, rather than actually offering them a way forward that does not involve targeting an entirely new display server API.
So "meanwhile" you would have apps that are not DPI aware without flag, DPI aware without flag and DPI aware with flag. And even crappier desktop as you have now for years to come.
The new API is not just for DPI; it is for many reasons, DPI is only one of the issues.
Most issues could probably solved by a variety of hacks. Several issues that don't concern yourself couldn't. The problem is that X consists of 40 years of hacks piled up on each other. THe X.org devs actively chose to stop further development and continue their work on wayland.
You are on the same side as the people bemoaning IPv6 and asking why we couldn't just use one of the unused flags in IPv4 to solve the address depletion issue. It sometimes makes sense to make incompatible changes.
And this is a not true, as evidenced by the fact even software ported from Windows (OBS) does it.
Here, Firefox uses dma-buf. Unless X11 exposes a special extension for exposing dma-buf, your client won't be able to do that.
And in practice, XShm-using OBS actually works better right now than this specific apparently Gnome-only dma-buf API. https://www.youtube.com/watch?v=kD70ur_xTmE
Just because some specific application works better (for some values of better) on the Xshm does not say anything. In year or two, the situation can be very different, permanently.
The same way Apple handles a PowerPC-compiled application from 1998.
By incrementing to a new major version number, and stating in the changelog that users are free to keep running the older version if their software won't be patched.
Does Wayland provide a better solution than that? No, and in addition it also breaks a lot of newer applications. We don't need to do a lot of math to figure out more people would miss Xorg than Wordperfect.
It doesn't handle them at all. There was a transition mechanism, to get users updated, but it wasn't maintained long term. You could not run PowerPC binaries from 1998 in 2005.
Apple expected their users to update the binaries for new architecture in the long term. In many cases, not only ISA and ABI changed, APIs too; good luck if your application used Quickdraw.
(Yes, I still do have coasters in the basement).
So compared to that, Wayland's Xwayland is too nice and too longterm.
I think the difference to xwit is that it does not work across windowmanagers/compositors, because much of what X11 used to do is now the job of the compositor, but I assume the users who script xwit likely also have a very tuned windowmanager, so it's unlike they switch window managers all the time and they could therefore just tune their environment for the same functionality as xwit.
I don't see any screen tearing when moving a window fast across the entire screen either, if that was the concern.
I also could set up large enough font sizes in cinnamon and browsers.