Am 19.05.21 um 11:34 schrieb Pekka Paalanen:
> On Wed, 12 May 2021 16:04:16 +0300
> Ville Syrjälä <> 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:
>>> -
>>> -
>>> -
>>> -
> ...
>>> Adoption:
>>> A KDE dev wants to implement the settings in the KDE settings GUI:
>>> 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.


> However, knowing what happened is going to be important for color
> calibration auditing:
> Yes, please, very much for read-only properties for the feedback part.
> Properties that both userspace and kernel will write are hard to deal
> with in general.
> Btw. "max bpc" I can kind of guess that conversion from framebuffer
> format to the wire bpc happens automatically and only as the final
> step, but "Broadcast RGB" is more complicated: is the output from the
> abstract pixel pipeline sent as-is and "Broadcast RGB" is just another
> inforframe bit to the monitor, or does "Broadcast RGB" setting actually
> change what happens in the pixel pipeline *and* set infoframe bits?
> My vague recollection is that framebuffer was always assumed to be in
> full range, and then if "Broadcast RGB" was set to limited range, the
> driver would mangle the pixel pipeline to convert from full to limited
> range. This means that it would be impossible to have limited range
> data in a framebuffer, or there might be a double-conversion by
> userspace programming a LUT for limited->full and then the driver
> adding full->limited. I'm also confused how full/limited works when
> framebuffer is in RGB/YCbCr and the monitor wire format is in RGB/YCbCr
> and there may be RGB->YCbCR or YCbCR->RGB conversions going on - or
> maybe even FB YCbCR -> RGB -> DEGAMMA -> CTM -> GAMMA -> YCbCR.
> I wish someone drew a picture of the KMS abstract pixel pipeline with
> all the existing KMS properties in it. :-)
> Thanks,
> pq
amd-gfx mailing list

Reply via email to