On Tue, 22 Jun 2021 19:06:43 +0200 Werner Sembach wse@tuxedocomputers.com wrote:
Am 19.05.21 um 11:34 schrieb Pekka Paalanen:
On Wed, 12 May 2021 16:04:16 +0300 Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote:
Hello,
In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm properties I propose 4 new properties: "preferred pixel encoding", "active color depth", "active color range", and "active pixel encoding"
Motivation:
Current monitors have a variety pixel encodings available: RGB, YCbCr 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0.
In addition they might be full or limited RGB range and the monitors accept different bit depths.
Currently the kernel driver for AMD and Intel GPUs automatically configure the color settings automatically with little to no influence of the user. However there are several real world scenarios where the user might disagree with the default chosen by the drivers and wants to set his or her own preference.
Some examples:
- While RGB and YCbCr 4:4:4 in theory carry the same amount of color information, some screens might look better on one
than the other because of bad internal conversion. The driver currently however has a fixed default that is chosen if available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change this currently is by editing and overloading the edid reported by the monitor to the kernel.
- RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some hardware might report that it supports the higher
port clock, but because of bad shielding on the PC, the cable, or the monitor the screen cuts out every few seconds when RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine without changing hardware. The drivers currently however always default to the "best available" option even if it might be broken.
- Some screens natively only supporting 8-bit color, simulate 10-Bit color by rapidly switching between 2 adjacent
colors. They advertise themselves to the kernel as 10-bit monitors but the user might not like the "fake" 10-bit effect and prefer running at the native 8-bit per color.
- Some screens are falsely classified as full RGB range wile they actually use limited RGB range. This results in
washed out colors in dark and bright scenes. A user override can be helpful to manually fix this issue when it occurs.
There already exist several requests, discussion, and patches regarding the thematic:
...
Adoption:
A KDE dev wants to implement the settings in the KDE settings GUI: https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370
Tuxedo Computers (my employer) wants to implement the settings desktop environment agnostic in Tuxedo Control Center. I will start work on this in parallel to implementing the new kernel code.
I suspect everyone would be happier to accept new uapi if we had multiple compositors signed up to implement it.
I think having Weston support for these would be good, but for now it won't be much of an UI: just weston.ini to set, and the log to see what happened.
Since a first version of the patch set is now feature complete, please let me know if a MR regarding this is started.
I'll try to remember that if I see someone else do it, but I'm also pretty sure I won't be writing it any time soon. Still a long way until it would be used with the color management work.
Thanks, pq