New uAPI for color management proposal and feedback request

[Pekka Paalanen]

On Tue, 22 Jun 2021 19:06:43 +0200
Werner Sembach <wse at 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 at 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:
> >>>
> >>> 1. 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.
> >>>
> >>> 2. 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.
> >>>
> >>> 3. 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.
> >>>
> >>> 4. 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:
> >>>
> >>> - https://gitlab.freedesktop.org/drm/amd/-/issues/476
> >>>
> >>> - https://gitlab.freedesktop.org/drm/amd/-/issues/1548
> >>>
> >>> - https://lkml.org/lkml/2021/5/7/695
> >>>
> >>> - https://lkml.org/lkml/2021/5/11/416
> >>>  
> > ...
> >  
> >>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20210623/9902fb4d/attachment.sig>