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

[tomas]

Its just a standard interface for managing how monitors are composed. Scripting it is entirely optional.

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?

[Volta]

It will find its niche with few percent of Linux users.

[aufkrawall]

Not sure about color profiles... since gnome does load them for displays with Wayland.

This is only GPU gamma ramps, the protocol that allows applications to perform color conversions to precisely map source gamuts to the native one of the display isn't yet complete.

[caligula]

What is the actual use case for randr? And then I mean on a high level, not "I have some very special setup where I run an xrandr script that triggers based on some criteria and that modifies the output to my displays in some custom way". What use case does it solve and how is the equivalent handled in Windows and MacOs?

The use case is, I want to perform these operations with scripts instead of a GUI.

[tomas]

The use case is, I want to perform these operations with scripts instead of a GUI.

Ok, so this is a very specialized feature that is not possible to achieve on any mainstream desktop OS like Windows or MacOs? Then I would say it's very niche and can't realistically be a very high priority feature. And the absence of randr for Wayland in general can simply not be a showstopper for the vast majority of users. I myself have used Linux as my primary desktop OS since 1996 and I have never felt the need for scripting my monitor setup, never even had the need to run xrandr directly at all to be honest. Besides, as I wrote, wlroots does in fact provide a randr replacement for Wayland.

[Neuro-Chef]

Ok, so this is a very specialized feature that is not possible to achieve on any mainstream desktop OS like Windows or MacOs? Then I would say it's very niche and can't realistically be a very high priority feature. And the absence of randr for Wayland in general can simply not be a showstopper for the vast majority of users. I myself have used Linux as my primary desktop OS since 1996 and I have never felt the need for scripting my monitor setup, never even had the need to run xrandr directly at all to be honest. Besides, as I wrote, wlroots does in fact provide a randr replacement for Wayland.

Well, multimonitor behaviour still sucks under Wayland. At least with the KDE Plasma Fedora spin, that can't remember the monitor placement if you use a notebook in a (USB-C?) docking station. At least if you want to still use your notebooks screen when it's not docked. sddm won't even show the login screen in docked mode unless I hit Enter and wait ~10 seconds. Typing the password in blind does not work although my user is the only one and preselected when the login screen finally appears, so I assume it runs like it has no display until then. Yes, UEFI output and boot animation show up fine before that.
But hey; this also sucks with X.Org, just a little less. And xrandr helps keeping screens virtually active even when turned off to save energy if one wants to do this. For Cinnamon I found it easier to just turn them on and/or off in the correct order only, it's just not really intuitive.

[tomas]

Well, multimonitor behaviour still sucks under Wayland...

No, what you're saying is that the implementation of Wayland in KDE sucks when it comes to monitor setup.

At least with the KDE Plasma Fedora spin, that can't remember the monitor placement if you use a notebook in a (US?) docking station. At least if you want to still use your notebooks screen when it's not docked. sddm won't even show the login screen in docked mode unless I hit Enter and wait ~10 seconds. Typing the password in blind does not work although my user is the only one and preselected when the login screen finally appears, so I assume it runs like it has no display until then. Yes, UEFI output and boot animation show up fine before that.

These are just bugs in KDE. Has nothing to do (I assume) with wayland. They need to be fixed in KDE. If the same seup works in Gnome wayland or in Sway, then it is not related at all to Wayland.

But hey; this also sucks with X.Org, just a little less. And xrandr helps keeping screens virtually active even when turned off to save energy if one wants to do this:

Then I'd say xrandr is a bandaid to work around bugs. Just fix the bugs.

[lectrode]

What is the actual use case for randr? And then I mean on a high level, not "I have some very special setup where I run an xrandr script that triggers based on some criteria and that modifies the output to my displays in some custom way". What use case does it solve and how is the equivalent handled in Windows and MacOs?

This is useful in that it provides a standard method for changing display output regardless of the desktop environment, which is especially useful for online documentation (no need to explain how to do it per desktop in a GUI that might change, or might not support all available features like scaling).

MacOS and Windows do not explicitly require this, as they only have a single desktop. Despite this, Windows at least still supports changing some display settings via wmic (wmic desktopmonitor create screenheight=1920, screenwidth=1080 ) and powershell (Set-DisplayResolution -Width 1920 -Height 1080 ). No idea about MacOS.

[arQon]

(snip)

jfc, can you just not stop with the apologist and blame-shifting bullshit for even ONE post?!
"It's a KDE bug". "xrandr is just a workaround". "It's a specialized feature then, because *I* don't use it and nobody else matters". etc etc etc.

randr is needed for, among other things: setting the resolution of a virtual display nicely, rotating the screen if you physically rotate a monitor into portrait, changing to a lower rez for games. But yeah, none of those are "real" use cases, because you're not actually looking for use cases - you're just looking for ways to make it someone else's fault that wayland doesn't support it.

It's handled in "other OSes" the same way that it's handled in X: by the developers understanding that it's a necessary tool and competently implementing support for it decades ago, instead of complaining that it's too hard a problem to cope with and passing the buck on to someone else - just like with damn near everything else about wayland.

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.

[pal666]

This is useful in that it provides a standard method for changing display output regardless of the desktop environment, which is especially

insecure

Windows at least still supports changing some display settings via wmic (wmic desktopmonitor create screenheight=1920, screenwidth=1080 ) and powershell (Set-DisplayResolution -Width 1920 -Height 1080 ). No idea about MacOS.

gnome does it via dbus which can be scripted