X.Org Server 21.1 RC1 Released With VRR Support For Modesetting Driver, Other Features

[yump]

https://github.com/emersion/wlr-randr

For wlroots based compositors like Sway, gamescope, KwinFT.
Gnome does its own and its monitor outputs works fine in Wayland as far as I can tell. If it does not work ok then that would just be a bug that need to be fixed, so Gnome for Wayland does not need some "rand" equivalent. Or am I missing something?

You're missing --newmode. There's no way to control the actual video signal timing parameters, which is useful for overclocking your monitor's refresh rate, or using a lower refresh rate with a high pixel clock and vertical front porch to minimize tearing visibility, or matching multiple monitors' video modes exactly (and in a mode with a generous vertical front porch) to allow AMDGPU to change memory clocks.

[tomas]

[skip long rant...]
....That's not to say it doesn't have the POTENTIAL to cause some crappy outcomes, because it does. But "OMG this is too hard, let's just run away" is wayland's answer to basically EVERY nontrivial problem - which is a big part of why it's still not ready even after all this time.

It is solved

https://github.com/emersion/wlr-randr

If gnome does not want to base their compositor on wlroots then that is their decision. Kwin currently does neither, while the KwinFT fork does.

[Sonadow]

It is solved

https://github.com/emersion/wlr-randr

If gnome does not want to base their compositor on wlroots then that is their decision. Kwin currently does neither, while the KwinFT fork does.

Why should Gnome use it when Mutter already works well enough.

[tomas]

You're missing --newmode. There's no way to control the actual video signal timing parameters, which is useful for overclocking your monitor's refresh rate, or using a lower refresh rate with a high pixel clock and vertical front porch to minimize tearing visibility, or matching multiple monitors' video modes exactly (and in a mode with a generous vertical front porch) to allow AMDGPU to change memory clocks.

Those things are either bugs or limitations of the current monitor setup configuration in Gnome Wayland. Then you report the bugs or limitations and they may be fixed. If the developers agree with your analysis. It does not need "xrandr" for Wayland in order to be fixed. People are mixing up a specific implementation detail of X with the actual use cases. How something is solved in for example Gnome Wayland regarding monitor configuration is an implementation detail of Gnome. For wlroots based compositors I guess it would be wlr-randr or perhaps something else. What we do know is that we do NOT strictly need xrandr for Wayland. That is simply nonsense. You need your monitor configuration to work. How it is achieved is a separate question. Saying that Wayland is not ready because it lacks a 100% compatible xrandr (incuding bug compatible and allowing broken configs) is simply wrong.

[tomas]

Why should Gnome use it when Mutter already works well enough.

That is exactly my point. It doesn't. Xrandr is an implementation detail of X. Mutter does not need it. Wlroot has something called wlr-randr that it uses.

[yump]

tomas I can 100% guarantee that the Gnome developers will not agree with my analysis. Facilitating technically-savvy poor people running their 60 Hz monitors at 72 Hz is the antithesis of everything Gnome stands for.

[tomas]

tomas I can 100% guarantee that the Gnome developers will not agree with my analysis. Facilitating technically-savvy poor people running their 60 Hz monitors at 72 Hz is the antithesis of everything Gnome stands for.

Ok, and in that case you will simply have to run something else that agrees with your use cases. I'm sorry.

[MrCooper]

Afaik xorg has support for monitor color profiles

Not that I know of. Xorg mainly just allows any client to more or less directly clobber the gamma LUTs. (See below why this approach is no-no with Wayland)

Gnome Shell crash restarts the shell on Xorg, but takes down the whole Wayland session.

That's a GNOME issue, not a Wayland one. Addressing Wayland robustness describes how Wayland clients can be made robust vs compositor crashes.

It's not that color profiles "don't work" on wayland, it's that the wayland devs explicitly refuse to support it.

?

A Wayland compositor can apply monitor profiles for its output, no Wayland protocol needed for that. Wayland protocol extensions for full application colour management and HDR support (I wouldn't put any money on the latter showing up in Xorg ever) are currently being worked on. Given the complexity of the subject matter and the Wayland protocol rules, it's going to be some time before these are marked stable and become widely available though.

Likewise for randr.

Yes, Wayland design principles forbid normal clients from making global configuration changes which affect other clients (like when a game crashes and leaves the desktop at the wrong resolution with Xorg). This kind of configuration is done via DE specific mechanisms instead.

[kozman]

As a Windows guy who's dabbled in Linux since the mid-90s, I've seen a lot of arguments of why XServer sucks. I'm glad to see some renewed interest in keeping XServer alive but I wonder if 21.1 will just be 3 years worth of bug fixes and a smattering of new-ish features but just a new paint job...on a turd? Don't get me wrong, if XServer "just works" but it has all this ancient cruft and baggage being dragged along with it and makes any newcomers who want to fix it up run for the friggin' doors when they peek under the hood, then why keep the ancient cruft in if it's treated as, basically, radioactive? It's no surprise NO ONE wants to commit to supporting it for, what, 10 years if they decide to be a release manager? No one wants to deal with the baggage.

The argument that "it's buggy", has "tons of security holes", etc is what I've read in the forums for well over a decade. Is it due to this ancient cruft dragging the project down or has it painted itself into a corner trying to be everything for everyone but not progress because it's hamstrung by it's user base? If the devs have dug themselves into a hole, should they not stop digging? In 2021, I think it's too huge of an ask to have someone commit XX amount of years to supporting it. Rolling release seems logical if no one wants to step up full time. All these companies who've benefited financially (NVidia, I'm GLARING at you) could surely hire one poor schmuck to work on development.

3 years in Internet time might as well be a decade but I'd still love to see some benchmarks of 21.1RC against current 1.20.13 to see if it's *really* made any progress in the 3 years of being in maintenance mode. I've yet to see one benchmark out there of even the previous 21.1 beta. NOT ONE! That's very telling IMHO. Maybe the train has already left the building?

Michael, care to step up to the plate?

[s9209122222]

The Xrandr feature in Wayland is needed, there is no way to change output format in Gnome Wayland.
The output format of AMD GPU is YCbCr444, but I want to output RGB444.