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.
> That's the difficult part. You are welcome to try, though!
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.
> 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"
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.
> I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, but changing them to support an entirely new display server protocol with its on set of problems is ... nice, clean solution?
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.
It is just setting a new property. The discussion here I thought was what is required to distinguish a client that is DPIaware versus one that it is not, for use by the compositor to decide whether to scale it transparently or not.
It's not just setting a new property. Meanwhile, today, you have clients that are dpi aware and are not setting the property. And they all will be out in the wild for an undetermined amount of time (because stuff works for the application developers, why bother?). If you do not handle them anyway, your users will complain that your desktop is broken.
It is just setting a new property. I am not sure we're on the same page here, but if your existing client is DPI-aware, and you just want to let the compositor know it, then it is a one-line change in your client.
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.
Because that "meanwhile" takes years. There are still clients that use libX11 ("it works for them") instead of libxcb. libxcb was introduced in 2003.
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.
I specifically qualified it with efficiently. As in, when the surface is in the GPU memory, the software doesn't have to read it over PCIe bus and then put it back into another buffer for the encoder; but that the encoder can do zero-copy encoding in the GPU memory.
Here, Firefox uses dma-buf. Unless X11 exposes a special extension for exposing dma-buf, your client won't be able to do that.
You said it yourself. I even believe that extension already exists since it must be going on inside DRI3 for some EGL/VK extensions to work right now. Don't think it worth to create an entirely new display server API for just this.
dma-buf is linux-specific, not Gnome specific. It is buffer management on GPUs; it is the low-level API that Mesa and libva, and yes, DRI too, build on top.
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.
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.