wlroots
wlroots copied to clipboard
swaywm
drm backend: set "Broadcast RGB" = "Full" for all connections
I have a new monitor which has three similar modes:
- 3840x2160 @ 59.939999 Hz
- 3840x2160 @ 60.000000 Hz
- 3840x2160 @ 59.997002 Hz
The last one works fine, but the first two have issues displaying colors, because the "Broadcast RGB" property on the connector defaults to "Auto" which means "Limited 16:235", squashing the dynamic range.
Since there is really no way for a sway user to know that 3840x2160@60Hz displays colors poorly, while [email protected] will be fine, I was using the wrong mode for weeks.
This patch causes wlroots to always set "Broadcast RGB" = "Full", which I think most people want.
- It doesn't seem like switching to "Full" unconditionally is a good idea, as TVs tend to use "Limited" instead.
- "Broadcast RGB" is an Intel-specific property.
1. It doesn't seem like switching to "Full" unconditionally is a good idea, as TVs tend to use "Limited" instead.
If it won't be the default, then it would be nice if sway could inform the user which modes use the limited mode; looking at the driver the logic seems to be in drm_default_rgb_quant_range(); it seems like userspace can only guess unless it copied all that logic. The aspect ratio flags seem to be a clue.
Do you have any other ideas for how it might be done? Perhaps setting full just for DP.
2. "Broadcast RGB" is an Intel-specific property.
Yes, I wonder how other drivers handle it. In regards to the patch, if the property doesn't exist it won't cause an issue.
Its still a good idea even on TVs to always use Full. Most TVs will autodetect, since its trivial to do, and adjust accordingly. Some let you override it, but not as many as you think always assume its always going to be limited. Furthermore, HDR is a thing now, and a lot of HDR content these days, including all of youtube, is in full range. Hence its not unreasonable to assume HDR TVs would also expect full-range. Losing 10% of your dynamic range (possibly more depending on dithering) with HDR is much more fatal than with bt709 (IEC61966-2.1) gamma. Also, a DisplayPort connection is guaranteed to use full range, just like DVI. And embedded, transparent DP <=> HDMI converters exist, which complicates assumptions further. Autodetection will result in more fragile configuration, even if you use EDID parsing. In fact, most TVs have broken/unreliable EDID, and I'd be willing to bet the number is higher than TVs that assume limited range RGB always.. If you need a reference on how much will break, take a look at interlaced modes: wlroots has disabled them for years and no one has complained.
I see there was a proposed DRM_MODE_FLAG_CEA_861_CE_MODE flag, I wonder if it has any chance of being implemented.
23:35 <vsyrjala> yes. "ce" modes use limited range, "it" modes use full range
23:43 <vsyrjala> this is one of those things we can't get it right 100% of the time due to broken displays
23:45 <vsyrjala> and sadly we don't know whether broken or non-broken display are more common
I'd still like to make this a standard property before starting to use it.
I’m sure you are better informed but from here it looks like that patch to lkml that’s adds that standard property from a few months ago has stalled.
Yes, those patches need some work. For reference:
- Introduces a new standard prop: https://lists.freedesktop.org/archives/dri-devel/2020-April/262153.html
- Adds a TODO: https://lists.freedesktop.org/archives/dri-devel/2020-June/268149.html
Ping again, been running this since it was posted, had no problems, already had to help out one person who was wondering why colors look washed out.
This email thread also suggests that we should stick to full range unconditionally (especially when we'll implement color management): https://lists.freedesktop.org/archives/dri-devel/2020-October/283396.html
This PR is still blocked on registering the property as a standard one.
More info on turning "Broadcast RGB" into a generic prop: https://dri.freedesktop.org/docs/drm/gpu/todo.html#consolidate-custom-driver-modeset-properties
This email thread also suggests that we should stick to full range unconditionally (especially when we'll implement color management): https://lists.freedesktop.org/archives/dri-devel/2020-October/283396.html
This PR is still blocked on registering the property as a standard one.
Is this the only blockage for this patch?
Because in this patchset https://lkml.org/lkml/2021/6/18/294, I standardized "Broadcast RGB" and implemented it for Intel and AMD. And if you say this MR is ready to be merged once the patch got accepted it would help with: https://www.kernel.org/doc/html/v5.12/gpu/drm-uapi.html#open-source-userspace-requirements
Yes, this is the only blocker. I trust @cyanreg that this is the correct thing to do. This patch also needs to be rebased.
I'm still using this locally and rebasing if needed. Repo is https://github.com/cyanreg/wlroots if you need it for now.
Yes, this is the only blocker. I trust @cyanreg that this is the correct thing to do. This patch also needs to be rebased.
rebased
Furthermore, HDR is a thing now, and a lot of HDR content these days, including all of youtube, is in full range.
All HDR content on Youtube is limited range. All Blu-rays are limited. All DVDs. Also streams. Only some masters and stuff and Dolby Vision profile 5 is full.
Not all HDR on youtube is limited-range, some is full range. Not all Blu-Rays are limited-range, since some Dolby Vision HDR is full range. Who cares about DVDs, it's 2021. They're badly-mastered interlaced garbage anyway. Not all streams are limited-range, twitch happily accepts full-range, and in fact, AMD hardware encoders by default encode in full-range. I estimate about 20-30% of twitch streams are full-range.
And finally, All computer monitors are full-range. All. Not some. All. If they accept RGB, and are a monitor meant for computers, they operate on full-range. All TVs made in the past 15 years with a digital input accept full-range. All of them also autodetect its presence and adjust their settings accordingly. In fact, outputting limited-range is more likely to create confusion on our side, since nothing to do with computers accepts or even acknowledges limited-range RGB. No codec, including AV1 nor VP9, can signal limited-range RGB either, only full-range.
Not all Blu-Rays are limited-range, since some Dolby Vision HDR is full range.
Blu-rays' Dolby Vision does not support full range, since profile 5 of DV is not supported on Blu-ray.
some is full range.
Please give me a link. Most HDR content is limited, so I doubt anybody uses full.
They're badly-mastered interlaced garbage anyway.
Most are progressive inside fake interlaced container. Google soft telecine flags.
All computer monitors are full-range
This has nothing to with range of BTW mostly YCbCr HDR.
nothing to do with computers accepts or even acknowledges limited-range RGB.
That is a bug in ffmpeg.
No codec, including AV1 nor VP9, can signal limited-range RGB either, only full-range.
You really know nothing do you? See https://trac.ffmpeg.org/ticket/9374#comment:3 You are a ffmpeg dev after all, it is crazy to not know that.
You really know nothing do you?
Please remain civil. This tone is not appropriate.
This tone is not appropriate.
I think he knows all it, because he is active ffmpeg dev.
- There's no "he".
- That's enough. If you're coming here just to bash people, you're not welcome.
wlroots has migrated to gitlab.freedesktop.org. This pull request has been moved to:
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/2310