GNOME Bugzilla – Bug 774742
xrandr equivalent in wayland (wlrandr ?)
Last modified: 2021-07-05 13:53:07 UTC
Hello, AFAIK there is no xrandr equivalent in wayland. It seem that there is a wlrandr proposal but I don't think it's implemented in mutter for now. https://lists.freedesktop.org/archives/wayland-devel/2013-March/007872.html https://lists.freedesktop.org/archives/wayland-devel/2014-April/014091.html IMHO it's not necessary to implement every options of xrandr in mutter but only the most useful one like: xrandr --output eDP1 --off --output HDMI1 --auto xrandr --output eDP1 --brightness 0.3 ... As you can see there is some concern about this feature: http://www.forums.fedoraforum.org/showthread.php?t=312000 Thanks !
A large use case for this is Redshift/F.lux for screen softening. These are the two largest screen softening programs out there, and both are currently broken in wayland because of missing xrandr support. Would love to have wayland and redshift in my life at the same time, as do many of us, but as it currently stands this is not an option. Right now I know a ton of us are opting for X11/Redshift and f.lux as we put our bodies/eyes over anything else. This addition would go a long way to bringing us on board with wayland/mutter. Thanks for the consideration.
I've recently encountered the same issue, but for a different use case. My main desktop consists of multiple screens, that I like to shuffle around as needed between the main Fedora OS and a dedicated GPU passthrough Windows VM. In order for the screens to switch output, all I had to do on X11 was to call "xrandr --output HDMI1 --off" and launch the VM "virsh start win". This could easily be integrated in a single .desktop launcher and made transparent for the user. I hope you can understand how such functionality can be useful in a variety of cases, and having an xrandr equivalent would be very much appreciated. Thank you!
All the classic SDL games also require gamma controls. Here is the Weston feature request: https://bugs.freedesktop.org/show_bug.cgi?id=99406
(In reply to Luke from comment #3) > All the classic SDL games also require gamma controls. Here is the Weston > feature request: https://bugs.freedesktop.org/show_bug.cgi?id=99406 That will be done by color managed surfaces, not by some configuration API.
(In reply to Luke from comment #3) > All the classic SDL games also require gamma controls. Here is the Weston > feature request: https://bugs.freedesktop.org/show_bug.cgi?id=99406 (In reply to Jonas Ådahl from comment #4) > (In reply to Luke from comment #3) > > All the classic SDL games also require gamma controls. Here is the Weston > > feature request: https://bugs.freedesktop.org/show_bug.cgi?id=99406 > > That will be done by color managed surfaces, not by some configuration API. With all due respect, but both of you clearly do not seem to know what that request to be able to adjust the RGB Limited/Full Range (16-235 vs. 0-255) actually is about. It has nothing to do with "SDL games" or games at all and it is not about gamma control. It's about altering in which format the HDMI/DisplayPort/DVI-D port is outputting.
SDL games use xrandr to set Gamma. So we need an equivalent in Wayland. Daniel Stone said as much in the Weston version of this feature request: https://gitlab.freedesktop.org/wayland/weston/issues/87 Daniel Stone 2017-01-17 10:15:48 UTC (In reply to Luke from comment #6) > Will that also address the gamma issue described in Bug 99040? For the exact case you're describing (legacy X11 clients), eventually but not immediately.
Atomic mode setting support has landed in mutter: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488
> SDL games use xrandr to set Gamma. So we need an equivalent in Wayland. SDL games either need to stop assuming they can configure the gamma ramps, or they will eventually need to be color managed (or rather, SDL would need to emulate setting the gamma by applying color management metadata to the surface). This is not something that works today however.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.