KDE Lands Wayland Fractional Scaling Support

[Sho_]

KWin has a plugin API. I think Weston (the reference implementation) may as well, but I'm actually not sure.

[Sho_]

No, in this case of "display compositor" it is not. If you think it is, then you have an error in the design of the protocol.

I don't have the time anymore to read the rest of your post (I did skim it and it mostly seemed to be incorrect engineering stuff and summary judgements), but note this is not a property of how the protocol works, it's a property of how sockets and connections work.

I think the next step here is for you to design your own windowing (or desktop, if you prefer) system/stack and outcompete the alternatives to prove them wrong, but I predict you will learn some new stuff about operating systems and graphics hardware in the process, by running the numbers, etc. - which is good fun!

[Sho_]

Anyway, thank you for your time. It was a nice discussion. If nothing else, I think it is good for everyone to have an idea of which exact issues are contentious and what exactly is the disagreement.

This is true, I think we left the debate in a better state than we found it. Thanks for your time!

[Sho_]

How terrible could it be for the client to specify the exact frame ID? It's just a single integer.

Because you were asking in reference to me mentioning frame-perfect capture across outputs specifically: Wayland compositors support multiple outputs (e.g. different screens) and may well render frames to them independently, e.g. to optimize for different (or variable) refresh rates and low latency. "A single integer" can lose meaning then (surfaces may overlap more than one output), and you also don't want to convene with a client over any data (such as a numbering scheme) that may have to change when the scene does (for example outputs coming and going or output settings changing).

(There are some trade-ofs there; frame synchronizing animations across displays can conflict with optimizing for per-display latency, and so on.)

[theriddick]

Ok but whats the cost? is it still going to cause text and some apps to blur (especially non wayland compatible versions)

Also can wayland run 10bit color without breaking some apps? (unlike xorg which causes stuff like firefox and some other stuff to break, inc steam)

[Sho_]

I've not seen any valid use case for having any sort of global frame number/id - given that, the above sounds unnecessary complex and also in conflict with nice, simple, generic design. For example your proposal involves picking a primary, which can of course go away at any time. You also limit the frame rate to the frame rate of your primary, which for example means if someone has a 60hz primary and a 144hz aux, they don't get nice 144hz gaming on their aux. Next, users approach the dev's house with torches and pitchforks, while the poor dev is distracted and busy by trying to cover all the corner cases.

In your original example, you say "the client says at frame 6 that it would like to get a screen capture of frame 10". This is to me not a valid use case; the client isn't supposed to know about where, how and when the compositor is scheduling rendering, and whether there will ever be a frame 10. The user could, for example, switch off the monitor at any time and make the compositor not want to do any rendering at all.

Also, regarding your "bad, not synchronized" design: Not true. As message order is guaranteed, a compositor can absolutely honor a "give me a capture of the next frame for the capture region" request in a synchronous fashion.

In general, there's a very good reason why Wayland withholds information about global state from clients by default: In X11, being able to introspect and manipulate the scene made the system very vulnerable to badly-written applications, some of which of course can never be fixed, e.g. because they were never open source. This has in many cases then also hindered innovation by DEs. Examples are for example spherical support for VR if your apps make assumptions about the coordinate system, or X' botched virtual desktop sub-protocol preventing desktops from changing workspace management semantics, and many many others. It's very easy to trap yourself in a bad design once you design anything cooperative.

[Sho_]

Also can wayland run 10bit color without breaking some apps? (unlike xorg which causes stuff like firefox and some other stuff to break, inc steam)

HDR support for Wayland and other bits in the stack is in the works, but isn't ready for prime time yet.

[theriddick]

HDR support for Wayland and other bits in the stack is in the works, but isn't ready for prime time yet.

Well 10bit isn't exactly part of HDR. I was just hoping the basic 10bit (30bit under Linux) mode worked ok now, guess not

[Sho_]

Well 10bit isn't exactly part of HDR. I was just hoping the basic 10bit (30bit under Linux) mode worked ok now, guess not

Fair enough . Basic 30 bit should work: https://old.reddit.com/r/kde/comment...olor_ie_10bit/

[theriddick]

Yeah, but I also have another problem. AMD has yet to implement HDMI2.1 in the open drivers. (Intel and NVIDIA have parts if fully supported in open-drivers)