Hi, when using X, it's possible to adjust the Intel driver's Broadcast RGB setting via xrandr like this: xrandr --output OUTPUT --set "Broadcast RGB" "Full" or: xrandr --output OUTPUT --set "Broadcast RGB" "Limited 16:235" or: xrandr --output OUTPUT --set "Broadcast RGB" "Automatic" Unfortunately the Intel driver now sets this to "Automatic" by default and "Automatic" doesn't really set it properly all of the time: https://bugzilla.kernel.org/show_bug.cgi?id=94921 amdgpu and radeon apparently are also planned to get options to to adjust the RGB range / color space, see: https://bugs.freedesktop.org/show_bug.cgi?id=83226 When asking on #wayland on the freenode IRC channel, I was told that such an option would need to be added to the corresponding Wayland compositor and that I should submit a feature request for the corresponding Wayland compositor. So, could you pease add an option to adjust the RGB range? Regards
There's no kernel parameter for it, see: https://bugs.freedesktop.org/show_bug.cgi?id=96489 So if the Wayland compositor does not provide an option to adjust it, you're pretty much stuck.
This is a perfectly reasonable feature request IMO. I'd recommend implementing it after Weston's atomic modesetting series has landed, because there will be a lot of churn in the DRM-backend. https://bugs.freedesktop.org/show_bug.cgi?id=96489 says it would be controlled by a connector property, so it's completely generic. Might also be worth thinking about how we could allow controlling lots of such properties rather than just this one. As for plumbing, it requires some drm-backend specific interface additions in libweston, and then the actual config reading and setting in weston.
I guess this is the list of all those "connector properties": https://01.org/linuxgraphics/gfx-docs/drm/drm-kms-properties.html ?
Yes, once atomic has landed we can start dealing with colour management properly, including this. There's a little more to it, especially given that the ->set_dpms() hook is badly incompatible with atomic, per https://phabricator.freedesktop.org/T7621 - the DPMS requests arrive completely incoherently to repaint requests, which makes it difficult to implement correctly.
(Thinko: by set_dpms, I meant gamma. Which ties in here.)
(In reply to Daniel Stone from comment #5) > (Thinko: by set_dpms, I meant gamma. Which ties in here.) Daniel, Will that also address the gamma issue described in Bug 99040?
(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.
When will the feature be added to wayland? I can't believe that a modern display server doesn't have the ability to change the RGB range!
Any update on this?
Nope, the atomic series is still waiting for reviews. See: https://lists.freedesktop.org/archives/wayland-devel/2017-July/034484.html
Any update on this one?
(In reply to N. W. from comment #11) > Any update on this one? No, atomic is still in review. (In reply to laichiaheng from comment #8) > When will the feature be added to wayland? This is a not thing to be added to Wayland. It is a thing in each compositor separately.
(In reply to Pekka Paalanen from comment #12) > This is a not thing to be added to Wayland. It is a thing in each compositor > separately. Thanks, I realize that, hence why I submitted this bug against the Weston component. I've also requested the same for KWin and Mutter, see: https://bugs.kde.org/show_bug.cgi?id=375666 https://bugzilla.gnome.org/show_bug.cgi?id=777248 https://bugzilla.gnome.org/show_bug.cgi?id=781856
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/wayland/weston/issues/87.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.