New uAPI for color management proposal and feedback request

New uAPI for color management proposal and feedback request

[Werner Sembach]

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


Current State:

I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management

- "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
10 and does not check the max_bpc setting.

- "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
it's decided there).

- RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
YCbCr 4:2:0 on all monitors if possible.


Proposed Solution:

1. Add a new uAPI property "preferred pixel encoding", as a per port setting.

    - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476

    - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
value in the process. I think it would be better to have this feedback channel as a different, read-only property.

    - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
respect this setting

2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.

    - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
could a rename be handled?".

    - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
better place)

3. Strive for full implementation of "max bpc"

    - I need to double check the Intel HDMI code.

4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
settings in the drm_connector_state struct

    - Possible values are:

        - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)

        - unknown, undefined, full, limited

        - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420

    - it's the responsibility of the driver to update the values once the port configuration changes

    - if the driver does not support the feedback channels they are set to unknown

    - if the driver uses a non listed setting it should set the property to undefined

    - A more detailed description why I think these feedback channel are important and should be their own read-only
property can be found here: https://lkml.org/lkml/2021/5/11/339


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.


Questions:

I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
once it's fully implemented?

Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
put it in the drm_connector_state struct.

My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
setting properties afterwards. I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)

Kind regards,

Werner Sembach

[Intel-gfx] New uAPI for color management proposal and feedback request

[Werner Sembach]

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


Current State:

I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management

- "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
10 and does not check the max_bpc setting.

- "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
it's decided there).

- RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
YCbCr 4:2:0 on all monitors if possible.


Proposed Solution:

1. Add a new uAPI property "preferred pixel encoding", as a per port setting.

    - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476

    - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
value in the process. I think it would be better to have this feedback channel as a different, read-only property.

    - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
respect this setting

2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.

    - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
could a rename be handled?".

    - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
better place)

3. Strive for full implementation of "max bpc"

    - I need to double check the Intel HDMI code.

4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
settings in the drm_connector_state struct

    - Possible values are:

        - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)

        - unknown, undefined, full, limited

        - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420

    - it's the responsibility of the driver to update the values once the port configuration changes

    - if the driver does not support the feedback channels they are set to unknown

    - if the driver uses a non listed setting it should set the property to undefined

    - A more detailed description why I think these feedback channel are important and should be their own read-only
property can be found here: https://lkml.org/lkml/2021/5/11/339


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.


Questions:

I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
once it's fully implemented?

Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
put it in the drm_connector_state struct.

My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
setting properties afterwards. I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)

Kind regards,

Werner Sembach


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

New uAPI for color management proposal and feedback request

[Werner Sembach]

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


Current State:

I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management

- "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
10 and does not check the max_bpc setting.

- "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
it's decided there).

- RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
YCbCr 4:2:0 on all monitors if possible.


Proposed Solution:

1. Add a new uAPI property "preferred pixel encoding", as a per port setting.

    - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476

    - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
value in the process. I think it would be better to have this feedback channel as a different, read-only property.

    - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
respect this setting

2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.

    - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
could a rename be handled?".

    - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
better place)

3. Strive for full implementation of "max bpc"

    - I need to double check the Intel HDMI code.

4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
settings in the drm_connector_state struct

    - Possible values are:

        - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)

        - unknown, undefined, full, limited

        - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420

    - it's the responsibility of the driver to update the values once the port configuration changes

    - if the driver does not support the feedback channels they are set to unknown

    - if the driver uses a non listed setting it should set the property to undefined

    - A more detailed description why I think these feedback channel are important and should be their own read-only
property can be found here: https://lkml.org/lkml/2021/5/11/339


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.


Questions:

I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
once it's fully implemented?

Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
put it in the drm_connector_state struct.

My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
setting properties afterwards. I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)

Kind regards,

Werner Sembach


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Ville Syrjälä]

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
> 
> 
> Current State:
> 
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
> 
> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> 10 and does not check the max_bpc setting.

i915 does limit things below max_bpc for both HDMI and DP.

> 
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> it's decided there).

i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP
specs. Unfortunately as you already mentioned there are quite a few
monitors (DP monitors in particular) that don't implemnt the spec
correctly. IIRC later DP specs even relaxed the wording to say
that you can basically ignore the spec and do whatever you want.
Which I supose is just admitting defeat and concluding that there
is no way to get this right 100% of the time.

> 
> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
> 
> 
> Proposed Solution:
> 
> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
> 
>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
> 
>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
> 
>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> respect this setting
> 
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
> 
>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> could a rename be handled?".

IIRC there was an attempt to unify this. Not sure what happened to it.

> 
>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> better place)
> 
> 3. Strive for full implementation of "max bpc"
> 
>     - I need to double check the Intel HDMI code.
> 
> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> settings in the drm_connector_state struct
> 
>     - Possible values are:
> 
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
> 
>         - unknown, undefined, full, limited
> 
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
> 
>     - it's the responsibility of the driver to update the values once the port configuration changes
> 
>     - if the driver does not support the feedback channels they are set to unknown
> 
>     - if the driver uses a non listed setting it should set the property to undefined
> 
>     - A more detailed description why I think these feedback channel are important and should be their own read-only
> property can be found here: https://lkml.org/lkml/2021/5/11/339
> 
> 
> 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.

> 
> 
> Questions:
> 
> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> once it's fully implemented?
> 
> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> put it in the drm_connector_state struct.
> 
> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> setting properties afterwards.

For debugging we have dmesg/debugfs/etc. If we add new uapi IMO
it will have to have some real world use cases beyond debugging.

> I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
> 
> Kind regards,
> 
> Werner Sembach
> 

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Ville Syrjälä]

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
> 
> 
> Current State:
> 
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
> 
> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> 10 and does not check the max_bpc setting.

i915 does limit things below max_bpc for both HDMI and DP.

> 
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> it's decided there).

i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP
specs. Unfortunately as you already mentioned there are quite a few
monitors (DP monitors in particular) that don't implemnt the spec
correctly. IIRC later DP specs even relaxed the wording to say
that you can basically ignore the spec and do whatever you want.
Which I supose is just admitting defeat and concluding that there
is no way to get this right 100% of the time.

> 
> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
> 
> 
> Proposed Solution:
> 
> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
> 
>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
> 
>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
> 
>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> respect this setting
> 
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
> 
>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> could a rename be handled?".

IIRC there was an attempt to unify this. Not sure what happened to it.

> 
>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> better place)
> 
> 3. Strive for full implementation of "max bpc"
> 
>     - I need to double check the Intel HDMI code.
> 
> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> settings in the drm_connector_state struct
> 
>     - Possible values are:
> 
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
> 
>         - unknown, undefined, full, limited
> 
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
> 
>     - it's the responsibility of the driver to update the values once the port configuration changes
> 
>     - if the driver does not support the feedback channels they are set to unknown
> 
>     - if the driver uses a non listed setting it should set the property to undefined
> 
>     - A more detailed description why I think these feedback channel are important and should be their own read-only
> property can be found here: https://lkml.org/lkml/2021/5/11/339
> 
> 
> 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.

> 
> 
> Questions:
> 
> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> once it's fully implemented?
> 
> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> put it in the drm_connector_state struct.
> 
> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> setting properties afterwards.

For debugging we have dmesg/debugfs/etc. If we add new uapi IMO
it will have to have some real world use cases beyond debugging.

> I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
> 
> Kind regards,
> 
> Werner Sembach
> 

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Ville Syrjälä]

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
> 
> 
> Current State:
> 
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
> 
> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> 10 and does not check the max_bpc setting.

i915 does limit things below max_bpc for both HDMI and DP.

> 
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> it's decided there).

i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP
specs. Unfortunately as you already mentioned there are quite a few
monitors (DP monitors in particular) that don't implemnt the spec
correctly. IIRC later DP specs even relaxed the wording to say
that you can basically ignore the spec and do whatever you want.
Which I supose is just admitting defeat and concluding that there
is no way to get this right 100% of the time.

> 
> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
> 
> 
> Proposed Solution:
> 
> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
> 
>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
> 
>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
> 
>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> respect this setting
> 
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
> 
>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> could a rename be handled?".

IIRC there was an attempt to unify this. Not sure what happened to it.

> 
>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> better place)
> 
> 3. Strive for full implementation of "max bpc"
> 
>     - I need to double check the Intel HDMI code.
> 
> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> settings in the drm_connector_state struct
> 
>     - Possible values are:
> 
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
> 
>         - unknown, undefined, full, limited
> 
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
> 
>     - it's the responsibility of the driver to update the values once the port configuration changes
> 
>     - if the driver does not support the feedback channels they are set to unknown
> 
>     - if the driver uses a non listed setting it should set the property to undefined
> 
>     - A more detailed description why I think these feedback channel are important and should be their own read-only
> property can be found here: https://lkml.org/lkml/2021/5/11/339
> 
> 
> 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.

> 
> 
> Questions:
> 
> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> once it's fully implemented?
> 
> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> put it in the drm_connector_state struct.
> 
> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> setting properties afterwards.

For debugging we have dmesg/debugfs/etc. If we add new uapi IMO
it will have to have some real world use cases beyond debugging.

> I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
> 
> Kind regards,
> 
> Werner Sembach
> 

-- 
Ville Syrjälä
Intel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Simon Ser]

On Wednesday, May 12th, 2021 at 3:04 PM, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> > 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.

Sign me up. We already have a patch blocked by "Broadcast RGB"
standardization:

https://github.com/swaywm/wlroots/pull/2310

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Simon Ser]

On Wednesday, May 12th, 2021 at 3:04 PM, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> > 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.

Sign me up. We already have a patch blocked by "Broadcast RGB"
standardization:

https://github.com/swaywm/wlroots/pull/2310
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Simon Ser]

On Wednesday, May 12th, 2021 at 3:04 PM, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> > 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.

Sign me up. We already have a patch blocked by "Broadcast RGB"
standardization:

https://github.com/swaywm/wlroots/pull/2310
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 12.05.21 um 14:06 schrieb Werner Sembach:

> 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
>
>
> Current State:
>
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
>
> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> 10 and does not check the max_bpc setting.
>
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> it's decided there).
>
> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
>
>
> Proposed Solution:
>
> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
>
>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
>
>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
>
>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> respect this setting
>
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
>
>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> could a rename be handled?".
>
>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> better place)
>
> 3. Strive for full implementation of "max bpc"
>
>     - I need to double check the Intel HDMI code.
>
> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> settings in the drm_connector_state struct
>
>     - Possible values are:
>
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
>
>         - unknown, undefined, full, limited
>
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
>
>     - it's the responsibility of the driver to update the values once the port configuration changes
>
>     - if the driver does not support the feedback channels they are set to unknown
>
>     - if the driver uses a non listed setting it should set the property to undefined
>
>     - A more detailed description why I think these feedback channel are important and should be their own read-only
> property can be found here: https://lkml.org/lkml/2021/5/11/339
>
>
> 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.
>
>
> Questions:
>
> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> once it's fully implemented?
>
> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> put it in the drm_connector_state struct.
>
> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> setting properties afterwards. I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
>
> Kind regards,
>
> Werner Sembach
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
I found this: https://dri.freedesktop.org/docs/drm/gpu/todo.html#consolidate-custom-driver-modeset-properties as an
additional reference. (Thanks @emersion in https://github.com/swaywm/wlroots/pull/2310)

Re: New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 12.05.21 um 14:06 schrieb Werner Sembach:

> 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
>
>
> Current State:
>
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
>
> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> 10 and does not check the max_bpc setting.
>
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> it's decided there).
>
> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
>
>
> Proposed Solution:
>
> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
>
>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
>
>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
>
>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> respect this setting
>
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
>
>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> could a rename be handled?".
>
>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> better place)
>
> 3. Strive for full implementation of "max bpc"
>
>     - I need to double check the Intel HDMI code.
>
> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> settings in the drm_connector_state struct
>
>     - Possible values are:
>
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
>
>         - unknown, undefined, full, limited
>
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
>
>     - it's the responsibility of the driver to update the values once the port configuration changes
>
>     - if the driver does not support the feedback channels they are set to unknown
>
>     - if the driver uses a non listed setting it should set the property to undefined
>
>     - A more detailed description why I think these feedback channel are important and should be their own read-only
> property can be found here: https://lkml.org/lkml/2021/5/11/339
>
>
> 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.
>
>
> Questions:
>
> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> once it's fully implemented?
>
> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> put it in the drm_connector_state struct.
>
> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> setting properties afterwards. I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
>
> Kind regards,
>
> Werner Sembach
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
I found this: https://dri.freedesktop.org/docs/drm/gpu/todo.html#consolidate-custom-driver-modeset-properties as an
additional reference. (Thanks @emersion in https://github.com/swaywm/wlroots/pull/2310)

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 12.05.21 um 14:06 schrieb Werner Sembach:

> 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
>
>
> Current State:
>
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
>
> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> 10 and does not check the max_bpc setting.
>
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> it's decided there).
>
> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
>
>
> Proposed Solution:
>
> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
>
>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
>
>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
>
>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> respect this setting
>
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
>
>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> could a rename be handled?".
>
>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> better place)
>
> 3. Strive for full implementation of "max bpc"
>
>     - I need to double check the Intel HDMI code.
>
> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> settings in the drm_connector_state struct
>
>     - Possible values are:
>
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
>
>         - unknown, undefined, full, limited
>
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
>
>     - it's the responsibility of the driver to update the values once the port configuration changes
>
>     - if the driver does not support the feedback channels they are set to unknown
>
>     - if the driver uses a non listed setting it should set the property to undefined
>
>     - A more detailed description why I think these feedback channel are important and should be their own read-only
> property can be found here: https://lkml.org/lkml/2021/5/11/339
>
>
> 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.
>
>
> Questions:
>
> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> once it's fully implemented?
>
> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> put it in the drm_connector_state struct.
>
> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> setting properties afterwards. I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
>
> Kind regards,
>
> Werner Sembach
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
I found this: https://dri.freedesktop.org/docs/drm/gpu/todo.html#consolidate-custom-driver-modeset-properties as an
additional reference. (Thanks @emersion in https://github.com/swaywm/wlroots/pull/2310)

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 12.05.21 um 14:06 schrieb Werner Sembach:

> 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
>
>
> Current State:
>
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
>
> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> 10 and does not check the max_bpc setting.
>
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> it's decided there).
>
> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
>
>
> Proposed Solution:
>
> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
>
>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
>
>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
>
>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> respect this setting
>
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
>
>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> could a rename be handled?".
>
>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> better place)
>
> 3. Strive for full implementation of "max bpc"
>
>     - I need to double check the Intel HDMI code.
>
> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> settings in the drm_connector_state struct
>
>     - Possible values are:
>
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
>
>         - unknown, undefined, full, limited
>
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
>
>     - it's the responsibility of the driver to update the values once the port configuration changes
>
>     - if the driver does not support the feedback channels they are set to unknown
>
>     - if the driver uses a non listed setting it should set the property to undefined
>
>     - A more detailed description why I think these feedback channel are important and should be their own read-only
> property can be found here: https://lkml.org/lkml/2021/5/11/339
>
>
> 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.
>
>
> Questions:
>
> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> once it's fully implemented?
>
> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> put it in the drm_connector_state struct.
>
> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> setting properties afterwards. I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
>
> Kind regards,
>
> Werner Sembach
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
I found this: https://dri.freedesktop.org/docs/drm/gpu/todo.html#consolidate-custom-driver-modeset-properties as an
additional reference. (Thanks @emersion in https://github.com/swaywm/wlroots/pull/2310)

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Alex Deucher]

On Wed, May 12, 2021 at 9:04 AM 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:
> >
> > 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
> >
> >
> > Current State:
> >
> > I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
> >
> > - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> > resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> > doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> > special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> > 10 and does not check the max_bpc setting.
>
> i915 does limit things below max_bpc for both HDMI and DP.
>
> >
> > - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> > range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> > Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> > it's decided there).
>
> i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP
> specs. Unfortunately as you already mentioned there are quite a few
> monitors (DP monitors in particular) that don't implemnt the spec
> correctly. IIRC later DP specs even relaxed the wording to say
> that you can basically ignore the spec and do whatever you want.
> Which I supose is just admitting defeat and concluding that there
> is no way to get this right 100% of the time.
>
> >
> > - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> > possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> > theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> > YCbCr 4:2:0 on all monitors if possible.
> >
> >
> > Proposed Solution:
> >
> > 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
> >
> >     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
> >
> >     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> > value in the process. I think it would be better to have this feedback channel as a different, read-only property.
> >
> >     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> > https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> > respect this setting
> >
> > 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
> >
> >     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> > could a rename be handled?".
>
> IIRC there was an attempt to unify this. Not sure what happened to it.

Looks like this set could be resurrected:
https://lists.freedesktop.org/archives/dri-devel/2020-April/262153.html

Alex

>
> >
> >     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> > better place)
> >
> > 3. Strive for full implementation of "max bpc"
> >
> >     - I need to double check the Intel HDMI code.
> >
> > 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> > settings in the drm_connector_state struct
> >
> >     - Possible values are:
> >
> >         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> > from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
> >
> >         - unknown, undefined, full, limited
> >
> >         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
> >
> >     - it's the responsibility of the driver to update the values once the port configuration changes
> >
> >     - if the driver does not support the feedback channels they are set to unknown
> >
> >     - if the driver uses a non listed setting it should set the property to undefined
> >
> >     - A more detailed description why I think these feedback channel are important and should be their own read-only
> > property can be found here: https://lkml.org/lkml/2021/5/11/339
> >
> >
> > 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.
>
> >
> >
> > Questions:
> >
> > I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> > once it's fully implemented?
> >
> > Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> > put it in the drm_connector_state struct.
> >
> > My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> > setting properties afterwards.
>
> For debugging we have dmesg/debugfs/etc. If we add new uapi IMO
> it will have to have some real world use cases beyond debugging.
>
> > I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> > Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
> >
> > Kind regards,
> >
> > Werner Sembach
> >
>
> --
> Ville Syrjälä
> Intel

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Alex Deucher]

On Wed, May 12, 2021 at 9:04 AM 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:
> >
> > 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
> >
> >
> > Current State:
> >
> > I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
> >
> > - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> > resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> > doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> > special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> > 10 and does not check the max_bpc setting.
>
> i915 does limit things below max_bpc for both HDMI and DP.
>
> >
> > - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> > range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> > Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> > it's decided there).
>
> i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP
> specs. Unfortunately as you already mentioned there are quite a few
> monitors (DP monitors in particular) that don't implemnt the spec
> correctly. IIRC later DP specs even relaxed the wording to say
> that you can basically ignore the spec and do whatever you want.
> Which I supose is just admitting defeat and concluding that there
> is no way to get this right 100% of the time.
>
> >
> > - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> > possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> > theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> > YCbCr 4:2:0 on all monitors if possible.
> >
> >
> > Proposed Solution:
> >
> > 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
> >
> >     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
> >
> >     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> > value in the process. I think it would be better to have this feedback channel as a different, read-only property.
> >
> >     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> > https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> > respect this setting
> >
> > 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
> >
> >     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> > could a rename be handled?".
>
> IIRC there was an attempt to unify this. Not sure what happened to it.

Looks like this set could be resurrected:
https://lists.freedesktop.org/archives/dri-devel/2020-April/262153.html

Alex

>
> >
> >     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> > better place)
> >
> > 3. Strive for full implementation of "max bpc"
> >
> >     - I need to double check the Intel HDMI code.
> >
> > 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> > settings in the drm_connector_state struct
> >
> >     - Possible values are:
> >
> >         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> > from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
> >
> >         - unknown, undefined, full, limited
> >
> >         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
> >
> >     - it's the responsibility of the driver to update the values once the port configuration changes
> >
> >     - if the driver does not support the feedback channels they are set to unknown
> >
> >     - if the driver uses a non listed setting it should set the property to undefined
> >
> >     - A more detailed description why I think these feedback channel are important and should be their own read-only
> > property can be found here: https://lkml.org/lkml/2021/5/11/339
> >
> >
> > 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.
>
> >
> >
> > Questions:
> >
> > I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> > once it's fully implemented?
> >
> > Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> > put it in the drm_connector_state struct.
> >
> > My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> > setting properties afterwards.
>
> For debugging we have dmesg/debugfs/etc. If we add new uapi IMO
> it will have to have some real world use cases beyond debugging.
>
> > I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> > Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
> >
> > Kind regards,
> >
> > Werner Sembach
> >
>
> --
> Ville Syrjälä
> Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Alex Deucher]

On Wed, May 12, 2021 at 9:04 AM 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:
> >
> > 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
> >
> >
> > Current State:
> >
> > I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
> >
> > - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> > resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> > doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> > special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> > 10 and does not check the max_bpc setting.
>
> i915 does limit things below max_bpc for both HDMI and DP.
>
> >
> > - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> > range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> > Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> > it's decided there).
>
> i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP
> specs. Unfortunately as you already mentioned there are quite a few
> monitors (DP monitors in particular) that don't implemnt the spec
> correctly. IIRC later DP specs even relaxed the wording to say
> that you can basically ignore the spec and do whatever you want.
> Which I supose is just admitting defeat and concluding that there
> is no way to get this right 100% of the time.
>
> >
> > - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> > possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> > theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> > YCbCr 4:2:0 on all monitors if possible.
> >
> >
> > Proposed Solution:
> >
> > 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
> >
> >     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
> >
> >     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> > value in the process. I think it would be better to have this feedback channel as a different, read-only property.
> >
> >     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> > https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> > respect this setting
> >
> > 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
> >
> >     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> > could a rename be handled?".
>
> IIRC there was an attempt to unify this. Not sure what happened to it.

Looks like this set could be resurrected:
https://lists.freedesktop.org/archives/dri-devel/2020-April/262153.html

Alex

>
> >
> >     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> > better place)
> >
> > 3. Strive for full implementation of "max bpc"
> >
> >     - I need to double check the Intel HDMI code.
> >
> > 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> > settings in the drm_connector_state struct
> >
> >     - Possible values are:
> >
> >         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> > from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
> >
> >         - unknown, undefined, full, limited
> >
> >         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
> >
> >     - it's the responsibility of the driver to update the values once the port configuration changes
> >
> >     - if the driver does not support the feedback channels they are set to unknown
> >
> >     - if the driver uses a non listed setting it should set the property to undefined
> >
> >     - A more detailed description why I think these feedback channel are important and should be their own read-only
> > property can be found here: https://lkml.org/lkml/2021/5/11/339
> >
> >
> > 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.
>
> >
> >
> > Questions:
> >
> > I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> > once it's fully implemented?
> >
> > Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> > put it in the drm_connector_state struct.
> >
> > My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> > setting properties afterwards.
>
> For debugging we have dmesg/debugfs/etc. If we add new uapi IMO
> it will have to have some real world use cases beyond debugging.
>
> > I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> > Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
> >
> > Kind regards,
> >
> > Werner Sembach
> >
>
> --
> Ville Syrjälä
> Intel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 12.05.21 um 14:06 schrieb Werner Sembach:
> 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"

As an alternative/additional to the feedback channels: Maybe the kernel should not only communicate resolutions and
refresh rates of available modes, but also color capabilities.

I tested with a monitor, for example, that had several 4k@60Hz modes/timings offered by the edid, but only some of them
supported YCbCr 420.

>
> 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
>
>
> Current State:
>
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
>
> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> 10 and does not check the max_bpc setting.
>
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> it's decided there).
>
> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
>
>
> Proposed Solution:
>
> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
>
>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
>
>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
>
>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> respect this setting
>
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
>
>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> could a rename be handled?".
>
>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> better place)
>
> 3. Strive for full implementation of "max bpc"
>
>     - I need to double check the Intel HDMI code.
>
> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> settings in the drm_connector_state struct
>
>     - Possible values are:
>
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
>
>         - unknown, undefined, full, limited
>
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
>
>     - it's the responsibility of the driver to update the values once the port configuration changes
>
>     - if the driver does not support the feedback channels they are set to unknown
>
>     - if the driver uses a non listed setting it should set the property to undefined
>
>     - A more detailed description why I think these feedback channel are important and should be their own read-only
> property can be found here: https://lkml.org/lkml/2021/5/11/339
>
>
> 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.
>
>
> Questions:
>
> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> once it's fully implemented?
>
> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> put it in the drm_connector_state struct.
>
> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> setting properties afterwards. I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
>
> Kind regards,
>
> Werner Sembach
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 12.05.21 um 14:06 schrieb Werner Sembach:
> 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"

As an alternative/additional to the feedback channels: Maybe the kernel should not only communicate resolutions and
refresh rates of available modes, but also color capabilities.

I tested with a monitor, for example, that had several 4k@60Hz modes/timings offered by the edid, but only some of them
supported YCbCr 420.

>
> 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
>
>
> Current State:
>
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
>
> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> 10 and does not check the max_bpc setting.
>
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> it's decided there).
>
> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
>
>
> Proposed Solution:
>
> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
>
>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
>
>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
>
>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> respect this setting
>
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
>
>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> could a rename be handled?".
>
>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> better place)
>
> 3. Strive for full implementation of "max bpc"
>
>     - I need to double check the Intel HDMI code.
>
> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> settings in the drm_connector_state struct
>
>     - Possible values are:
>
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
>
>         - unknown, undefined, full, limited
>
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
>
>     - it's the responsibility of the driver to update the values once the port configuration changes
>
>     - if the driver does not support the feedback channels they are set to unknown
>
>     - if the driver uses a non listed setting it should set the property to undefined
>
>     - A more detailed description why I think these feedback channel are important and should be their own read-only
> property can be found here: https://lkml.org/lkml/2021/5/11/339
>
>
> 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.
>
>
> Questions:
>
> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> once it's fully implemented?
>
> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> put it in the drm_connector_state struct.
>
> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> setting properties afterwards. I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
>
> Kind regards,
>
> Werner Sembach
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 12.05.21 um 14:06 schrieb Werner Sembach:
> 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"

As an alternative/additional to the feedback channels: Maybe the kernel should not only communicate resolutions and
refresh rates of available modes, but also color capabilities.

I tested with a monitor, for example, that had several 4k@60Hz modes/timings offered by the edid, but only some of them
supported YCbCr 420.

>
> 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
>
>
> Current State:
>
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
>
> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
> 10 and does not check the max_bpc setting.
>
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
> it's decided there).
>
> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
>
>
> Proposed Solution:
>
> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
>
>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
>
>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
>
>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
> respect this setting
>
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
>
>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
> could a rename be handled?".
>
>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
> better place)
>
> 3. Strive for full implementation of "max bpc"
>
>     - I need to double check the Intel HDMI code.
>
> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
> settings in the drm_connector_state struct
>
>     - Possible values are:
>
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
>
>         - unknown, undefined, full, limited
>
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
>
>     - it's the responsibility of the driver to update the values once the port configuration changes
>
>     - if the driver does not support the feedback channels they are set to unknown
>
>     - if the driver uses a non listed setting it should set the property to undefined
>
>     - A more detailed description why I think these feedback channel are important and should be their own read-only
> property can be found here: https://lkml.org/lkml/2021/5/11/339
>
>
> 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.
>
>
> Questions:
>
> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
> once it's fully implemented?
>
> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
> put it in the drm_connector_state struct.
>
> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
> setting properties afterwards. I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
>
> Kind regards,
>
> Werner Sembach
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 5033 bytes --]

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:
> > 
> > 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.

However, knowing what happened is going to be important for color
calibration auditing:
https://gitlab.freedesktop.org/wayland/weston/-/issues/467

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 5033 bytes --]

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:
> > 
> > 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.

However, knowing what happened is going to be important for color
calibration auditing:
https://gitlab.freedesktop.org/wayland/weston/-/issues/467

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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 5033 bytes --]

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:
> > 
> > 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.

However, knowing what happened is going to be important for color
calibration auditing:
https://gitlab.freedesktop.org/wayland/weston/-/issues/467

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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Ville Syrjälä]

On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> 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:
> > > 
> > > 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.
> 
> However, knowing what happened is going to be important for color
> calibration auditing:
> https://gitlab.freedesktop.org/wayland/weston/-/issues/467
> 
> 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,

Well, there could be dithering and whatnot also involved. So it's
not super well specified atm either.

> 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?

It does indeed compress the actual pixel data. There was once a patch
porposed to introduce a new enum value that only sets the infoframe and
thus would allow userspace to pass through already limited range data.
Shouldn't be hard to resurrect that if needed.

> 
> 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. :-)

Here's an ugly one for i915:

    (input RGB vs. YCbCr?)
[FB] -> [YCbCr?] -> [YCbCr->RGB conversion     ] -> [plane blending] -> ...
      |             [YCbCr color range/encoding] |
      \ [RGB?] ----------------------------------/

                                           (output RGB limited vs. RGB full vs. YCbCr?)
... -> [DEGAMMA_LUT] -> [CTM] -> [GAMMA_LUT] -> [YCbCr?] -> [RGB->YCbCr conversion      ] -> [to port]
                                              |             [always BT.709/limited range]
                                              \ [RGB?] -> ...

... -> [RGB passthrough             ] -> [to port]
     | [Broadcast RGB=full or       ]
     | [Broadcast RGB=auto + IT mode]
     |
     \ [RGB full->limited conversion] -> [to port]
       [Broadcast RGB=limited or    ]
       [Broadcast RGB=auto + CE mode]

I guess having something like that in the docs would be nice. Not sure
if there's a way to make something that looks decent for html/etc.

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Ville Syrjälä]

On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> 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:
> > > 
> > > 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.
> 
> However, knowing what happened is going to be important for color
> calibration auditing:
> https://gitlab.freedesktop.org/wayland/weston/-/issues/467
> 
> 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,

Well, there could be dithering and whatnot also involved. So it's
not super well specified atm either.

> 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?

It does indeed compress the actual pixel data. There was once a patch
porposed to introduce a new enum value that only sets the infoframe and
thus would allow userspace to pass through already limited range data.
Shouldn't be hard to resurrect that if needed.

> 
> 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. :-)

Here's an ugly one for i915:

    (input RGB vs. YCbCr?)
[FB] -> [YCbCr?] -> [YCbCr->RGB conversion     ] -> [plane blending] -> ...
      |             [YCbCr color range/encoding] |
      \ [RGB?] ----------------------------------/

                                           (output RGB limited vs. RGB full vs. YCbCr?)
... -> [DEGAMMA_LUT] -> [CTM] -> [GAMMA_LUT] -> [YCbCr?] -> [RGB->YCbCr conversion      ] -> [to port]
                                              |             [always BT.709/limited range]
                                              \ [RGB?] -> ...

... -> [RGB passthrough             ] -> [to port]
     | [Broadcast RGB=full or       ]
     | [Broadcast RGB=auto + IT mode]
     |
     \ [RGB full->limited conversion] -> [to port]
       [Broadcast RGB=limited or    ]
       [Broadcast RGB=auto + CE mode]

I guess having something like that in the docs would be nice. Not sure
if there's a way to make something that looks decent for html/etc.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Ville Syrjälä]

On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> 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:
> > > 
> > > 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.
> 
> However, knowing what happened is going to be important for color
> calibration auditing:
> https://gitlab.freedesktop.org/wayland/weston/-/issues/467
> 
> 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,

Well, there could be dithering and whatnot also involved. So it's
not super well specified atm either.

> 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?

It does indeed compress the actual pixel data. There was once a patch
porposed to introduce a new enum value that only sets the infoframe and
thus would allow userspace to pass through already limited range data.
Shouldn't be hard to resurrect that if needed.

> 
> 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. :-)

Here's an ugly one for i915:

    (input RGB vs. YCbCr?)
[FB] -> [YCbCr?] -> [YCbCr->RGB conversion     ] -> [plane blending] -> ...
      |             [YCbCr color range/encoding] |
      \ [RGB?] ----------------------------------/

                                           (output RGB limited vs. RGB full vs. YCbCr?)
... -> [DEGAMMA_LUT] -> [CTM] -> [GAMMA_LUT] -> [YCbCr?] -> [RGB->YCbCr conversion      ] -> [to port]
                                              |             [always BT.709/limited range]
                                              \ [RGB?] -> ...

... -> [RGB passthrough             ] -> [to port]
     | [Broadcast RGB=full or       ]
     | [Broadcast RGB=auto + IT mode]
     |
     \ [RGB full->limited conversion] -> [to port]
       [Broadcast RGB=limited or    ]
       [Broadcast RGB=auto + CE mode]

I guess having something like that in the docs would be nice. Not sure
if there's a way to make something that looks decent for html/etc.

-- 
Ville Syrjälä
Intel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 7425 bytes --]

On Wed, 19 May 2021 16:49:35 +0300
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> > 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:
> > > > 
> > > > 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.
> > 
> > However, knowing what happened is going to be important for color
> > calibration auditing:
> > https://gitlab.freedesktop.org/wayland/weston/-/issues/467
> > 
> > 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,  
> 
> Well, there could be dithering and whatnot also involved. So it's
> not super well specified atm either.

I tend to forget that dithering is a thing. I guess it could be
temporal and/or spatial depending on hardware?

> > 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?  
> 
> It does indeed compress the actual pixel data. There was once a patch
> porposed to introduce a new enum value that only sets the infoframe and
> thus would allow userspace to pass through already limited range data.
> Shouldn't be hard to resurrect that if needed.

Right, thanks for confirming. I mentioned this mostly for Werner to
point out that existing properties might do surprising things.
Especially if one has looked at HDR related properties which only set
infoframe bits and nothing more.

> > 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. :-)  
> 
> Here's an ugly one for i915:
> 
>     (input RGB vs. YCbCr?)
> [FB] -> [YCbCr?] -> [YCbCr->RGB conversion     ] -> [plane blending] -> ...
>       |             [YCbCr color range/encoding] |
>       \ [RGB?] ----------------------------------/
> 
>                                            (output RGB limited vs. RGB full vs. YCbCr?)
> ... -> [DEGAMMA_LUT] -> [CTM] -> [GAMMA_LUT] -> [YCbCr?] -> [RGB->YCbCr conversion      ] -> [to port]
>                                               |             [always BT.709/limited range]
>                                               \ [RGB?] -> ...
> 
> ... -> [RGB passthrough             ] -> [to port]
>      | [Broadcast RGB=full or       ]
>      | [Broadcast RGB=auto + IT mode]
>      |
>      \ [RGB full->limited conversion] -> [to port]
>        [Broadcast RGB=limited or    ]
>        [Broadcast RGB=auto + CE mode]
> 
> I guess having something like that in the docs would be nice. Not sure
> if there's a way to make something that looks decent for html/etc.

It would be super useful indeed.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 7425 bytes --]

On Wed, 19 May 2021 16:49:35 +0300
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> > 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:
> > > > 
> > > > 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.
> > 
> > However, knowing what happened is going to be important for color
> > calibration auditing:
> > https://gitlab.freedesktop.org/wayland/weston/-/issues/467
> > 
> > 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,  
> 
> Well, there could be dithering and whatnot also involved. So it's
> not super well specified atm either.

I tend to forget that dithering is a thing. I guess it could be
temporal and/or spatial depending on hardware?

> > 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?  
> 
> It does indeed compress the actual pixel data. There was once a patch
> porposed to introduce a new enum value that only sets the infoframe and
> thus would allow userspace to pass through already limited range data.
> Shouldn't be hard to resurrect that if needed.

Right, thanks for confirming. I mentioned this mostly for Werner to
point out that existing properties might do surprising things.
Especially if one has looked at HDR related properties which only set
infoframe bits and nothing more.

> > 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. :-)  
> 
> Here's an ugly one for i915:
> 
>     (input RGB vs. YCbCr?)
> [FB] -> [YCbCr?] -> [YCbCr->RGB conversion     ] -> [plane blending] -> ...
>       |             [YCbCr color range/encoding] |
>       \ [RGB?] ----------------------------------/
> 
>                                            (output RGB limited vs. RGB full vs. YCbCr?)
> ... -> [DEGAMMA_LUT] -> [CTM] -> [GAMMA_LUT] -> [YCbCr?] -> [RGB->YCbCr conversion      ] -> [to port]
>                                               |             [always BT.709/limited range]
>                                               \ [RGB?] -> ...
> 
> ... -> [RGB passthrough             ] -> [to port]
>      | [Broadcast RGB=full or       ]
>      | [Broadcast RGB=auto + IT mode]
>      |
>      \ [RGB full->limited conversion] -> [to port]
>        [Broadcast RGB=limited or    ]
>        [Broadcast RGB=auto + CE mode]
> 
> I guess having something like that in the docs would be nice. Not sure
> if there's a way to make something that looks decent for html/etc.

It would be super useful indeed.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 7425 bytes --]

On Wed, 19 May 2021 16:49:35 +0300
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> > 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:
> > > > 
> > > > 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.
> > 
> > However, knowing what happened is going to be important for color
> > calibration auditing:
> > https://gitlab.freedesktop.org/wayland/weston/-/issues/467
> > 
> > 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,  
> 
> Well, there could be dithering and whatnot also involved. So it's
> not super well specified atm either.

I tend to forget that dithering is a thing. I guess it could be
temporal and/or spatial depending on hardware?

> > 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?  
> 
> It does indeed compress the actual pixel data. There was once a patch
> porposed to introduce a new enum value that only sets the infoframe and
> thus would allow userspace to pass through already limited range data.
> Shouldn't be hard to resurrect that if needed.

Right, thanks for confirming. I mentioned this mostly for Werner to
point out that existing properties might do surprising things.
Especially if one has looked at HDR related properties which only set
infoframe bits and nothing more.

> > 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. :-)  
> 
> Here's an ugly one for i915:
> 
>     (input RGB vs. YCbCr?)
> [FB] -> [YCbCr?] -> [YCbCr->RGB conversion     ] -> [plane blending] -> ...
>       |             [YCbCr color range/encoding] |
>       \ [RGB?] ----------------------------------/
> 
>                                            (output RGB limited vs. RGB full vs. YCbCr?)
> ... -> [DEGAMMA_LUT] -> [CTM] -> [GAMMA_LUT] -> [YCbCr?] -> [RGB->YCbCr conversion      ] -> [to port]
>                                               |             [always BT.709/limited range]
>                                               \ [RGB?] -> ...
> 
> ... -> [RGB passthrough             ] -> [to port]
>      | [Broadcast RGB=full or       ]
>      | [Broadcast RGB=auto + IT mode]
>      |
>      \ [RGB full->limited conversion] -> [to port]
>        [Broadcast RGB=limited or    ]
>        [Broadcast RGB=auto + CE mode]
> 
> I guess having something like that in the docs would be nice. Not sure
> if there's a way to make something that looks decent for html/etc.

It would be super useful indeed.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 12.05.21 um 19:59 schrieb Alex Deucher:
> On Wed, May 12, 2021 at 9:04 AM 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:
>>>
>>> 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
>>>
>>>
>>> Current State:
>>>
>>> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
>>>
>>> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
>>> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
>>> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
>>> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
>>> 10 and does not check the max_bpc setting.
>> i915 does limit things below max_bpc for both HDMI and DP.
>>
>>> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
>>> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
>>> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
>>> it's decided there).
>> i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP
>> specs. Unfortunately as you already mentioned there are quite a few
>> monitors (DP monitors in particular) that don't implemnt the spec
>> correctly. IIRC later DP specs even relaxed the wording to say
>> that you can basically ignore the spec and do whatever you want.
>> Which I supose is just admitting defeat and concluding that there
>> is no way to get this right 100% of the time.
>>
>>> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
>>> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
>>> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
>>> YCbCr 4:2:0 on all monitors if possible.
>>>
>>>
>>> Proposed Solution:
>>>
>>> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
>>>
>>>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
>>>
>>>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
>>> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
>>>
>>>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
>>> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
>>> respect this setting
>>>
>>> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
>>>
>>>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
>>> could a rename be handled?".
>> IIRC there was an attempt to unify this. Not sure what happened to it.
> Looks like this set could be resurrected:
> https://lists.freedesktop.org/archives/dri-devel/2020-April/262153.html
>
> Alex
Thanks, I will look into it.
>
>>>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
>>> better place)
>>>
>>> 3. Strive for full implementation of "max bpc"
>>>
>>>     - I need to double check the Intel HDMI code.
>>>
>>> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
>>> settings in the drm_connector_state struct
>>>
>>>     - Possible values are:
>>>
>>>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
>>> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
>>>
>>>         - unknown, undefined, full, limited
>>>
>>>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
>>>
>>>     - it's the responsibility of the driver to update the values once the port configuration changes
>>>
>>>     - if the driver does not support the feedback channels they are set to unknown
>>>
>>>     - if the driver uses a non listed setting it should set the property to undefined
>>>
>>>     - A more detailed description why I think these feedback channel are important and should be their own read-only
>>> property can be found here: https://lkml.org/lkml/2021/5/11/339
>>>
>>>
>>> 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.
>>
>>>
>>> Questions:
>>>
>>> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
>>> once it's fully implemented?
>>>
>>> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
>>> put it in the drm_connector_state struct.
>>>
>>> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
>>> setting properties afterwards.
>> For debugging we have dmesg/debugfs/etc. If we add new uapi IMO
>> it will have to have some real world use cases beyond debugging.
>>
>>> I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
>>> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
>>>
>>> Kind regards,
>>>
>>> Werner Sembach
>>>
>> --
>> Ville Syrjälä
>> Intel

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 12.05.21 um 19:59 schrieb Alex Deucher:
> On Wed, May 12, 2021 at 9:04 AM 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:
>>>
>>> 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
>>>
>>>
>>> Current State:
>>>
>>> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
>>>
>>> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
>>> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
>>> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
>>> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
>>> 10 and does not check the max_bpc setting.
>> i915 does limit things below max_bpc for both HDMI and DP.
>>
>>> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
>>> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
>>> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
>>> it's decided there).
>> i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP
>> specs. Unfortunately as you already mentioned there are quite a few
>> monitors (DP monitors in particular) that don't implemnt the spec
>> correctly. IIRC later DP specs even relaxed the wording to say
>> that you can basically ignore the spec and do whatever you want.
>> Which I supose is just admitting defeat and concluding that there
>> is no way to get this right 100% of the time.
>>
>>> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
>>> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
>>> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
>>> YCbCr 4:2:0 on all monitors if possible.
>>>
>>>
>>> Proposed Solution:
>>>
>>> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
>>>
>>>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
>>>
>>>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
>>> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
>>>
>>>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
>>> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
>>> respect this setting
>>>
>>> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
>>>
>>>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
>>> could a rename be handled?".
>> IIRC there was an attempt to unify this. Not sure what happened to it.
> Looks like this set could be resurrected:
> https://lists.freedesktop.org/archives/dri-devel/2020-April/262153.html
>
> Alex
Thanks, I will look into it.
>
>>>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
>>> better place)
>>>
>>> 3. Strive for full implementation of "max bpc"
>>>
>>>     - I need to double check the Intel HDMI code.
>>>
>>> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
>>> settings in the drm_connector_state struct
>>>
>>>     - Possible values are:
>>>
>>>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
>>> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
>>>
>>>         - unknown, undefined, full, limited
>>>
>>>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
>>>
>>>     - it's the responsibility of the driver to update the values once the port configuration changes
>>>
>>>     - if the driver does not support the feedback channels they are set to unknown
>>>
>>>     - if the driver uses a non listed setting it should set the property to undefined
>>>
>>>     - A more detailed description why I think these feedback channel are important and should be their own read-only
>>> property can be found here: https://lkml.org/lkml/2021/5/11/339
>>>
>>>
>>> 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.
>>
>>>
>>> Questions:
>>>
>>> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
>>> once it's fully implemented?
>>>
>>> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
>>> put it in the drm_connector_state struct.
>>>
>>> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
>>> setting properties afterwards.
>> For debugging we have dmesg/debugfs/etc. If we add new uapi IMO
>> it will have to have some real world use cases beyond debugging.
>>
>>> I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
>>> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
>>>
>>> Kind regards,
>>>
>>> Werner Sembach
>>>
>> --
>> Ville Syrjälä
>> Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 12.05.21 um 19:59 schrieb Alex Deucher:
> On Wed, May 12, 2021 at 9:04 AM 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:
>>>
>>> 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
>>>
>>>
>>> Current State:
>>>
>>> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management
>>>
>>> - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every
>>> resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range
>>> doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very
>>> special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and
>>> 10 and does not check the max_bpc setting.
>> i915 does limit things below max_bpc for both HDMI and DP.
>>
>>> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color
>>> range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set,
>>> Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how
>>> it's decided there).
>> i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP
>> specs. Unfortunately as you already mentioned there are quite a few
>> monitors (DP monitors in particular) that don't implemnt the spec
>> correctly. IIRC later DP specs even relaxed the wording to say
>> that you can basically ignore the spec and do whatever you want.
>> Which I supose is just admitting defeat and concluding that there
>> is no way to get this right 100% of the time.
>>
>>> - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is
>>> possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would
>>> theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to
>>> YCbCr 4:2:0 on all monitors if possible.
>>>
>>>
>>> Proposed Solution:
>>>
>>> 1. Add a new uAPI property "preferred pixel encoding", as a per port setting.
>>>
>>>     - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476
>>>
>>>     - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested
>>> value in the process. I think it would be better to have this feedback channel as a different, read-only property.
>>>
>>>     - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc
>>> https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 and add patches to amdgpu and i915 to
>>> respect this setting
>>>
>>> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting.
>>>
>>>     - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how
>>> could a rename be handled?".
>> IIRC there was an attempt to unify this. Not sure what happened to it.
> Looks like this set could be resurrected:
> https://lists.freedesktop.org/archives/dri-devel/2020-April/262153.html
>
> Alex
Thanks, I will look into it.
>
>>>     - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a
>>> better place)
>>>
>>> 3. Strive for full implementation of "max bpc"
>>>
>>>     - I need to double check the Intel HDMI code.
>>>
>>> 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic
>>> settings in the drm_connector_state struct
>>>
>>>     - Possible values are:
>>>
>>>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer
>>> from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable)
>>>
>>>         - unknown, undefined, full, limited
>>>
>>>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420
>>>
>>>     - it's the responsibility of the driver to update the values once the port configuration changes
>>>
>>>     - if the driver does not support the feedback channels they are set to unknown
>>>
>>>     - if the driver uses a non listed setting it should set the property to undefined
>>>
>>>     - A more detailed description why I think these feedback channel are important and should be their own read-only
>>> property can be found here: https://lkml.org/lkml/2021/5/11/339
>>>
>>>
>>> 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.
>>
>>>
>>> Questions:
>>>
>>> I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI
>>> once it's fully implemented?
>>>
>>> Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would
>>> put it in the drm_connector_state struct.
>>>
>>> My way forward would be to implement the feedback channels first, because they can be very useful for debugging the
>>> setting properties afterwards.
>> For debugging we have dmesg/debugfs/etc. If we add new uapi IMO
>> it will have to have some real world use cases beyond debugging.
>>
>>> I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for
>>> Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP)
>>>
>>> Kind regards,
>>>
>>> Werner Sembach
>>>
>> --
>> Ville Syrjälä
>> Intel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 19.05.21 um 15:49 schrieb Ville Syrjälä:
> On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
>> 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:
>>>>
>>>> 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.
>>
>> However, knowing what happened is going to be important for color
>> calibration auditing:
>> https://gitlab.freedesktop.org/wayland/weston/-/issues/467
>>
>> 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,
> Well, there could be dithering and whatnot also involved. So it's
> not super well specified atm either.
>
>> 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?
> It does indeed compress the actual pixel data. There was once a patch
> porposed to introduce a new enum value that only sets the infoframe and
> thus would allow userspace to pass through already limited range data.
> Shouldn't be hard to resurrect that if needed.

For the time being I try to keep the functionality of Broadcast RGB the same and just port it over to AMDGPU, but i
haven't looked into it in detail yet.

>
>> 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. :-)
> Here's an ugly one for i915:
>
>     (input RGB vs. YCbCr?)
> [FB] -> [YCbCr?] -> [YCbCr->RGB conversion     ] -> [plane blending] -> ...
>       |             [YCbCr color range/encoding] |
>       \ [RGB?] ----------------------------------/
>
>                                            (output RGB limited vs. RGB full vs. YCbCr?)
> ... -> [DEGAMMA_LUT] -> [CTM] -> [GAMMA_LUT] -> [YCbCr?] -> [RGB->YCbCr conversion      ] -> [to port]
>                                               |             [always BT.709/limited range]
>                                               \ [RGB?] -> ...
>
> ... -> [RGB passthrough             ] -> [to port]
>      | [Broadcast RGB=full or       ]
>      | [Broadcast RGB=auto + IT mode]
>      |
>      \ [RGB full->limited conversion] -> [to port]
>        [Broadcast RGB=limited or    ]
>        [Broadcast RGB=auto + CE mode]
>
> I guess having something like that in the docs would be nice. Not sure
> if there's a way to make something that looks decent for html/etc.
>

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 19.05.21 um 15:49 schrieb Ville Syrjälä:
> On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
>> 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:
>>>>
>>>> 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.
>>
>> However, knowing what happened is going to be important for color
>> calibration auditing:
>> https://gitlab.freedesktop.org/wayland/weston/-/issues/467
>>
>> 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,
> Well, there could be dithering and whatnot also involved. So it's
> not super well specified atm either.
>
>> 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?
> It does indeed compress the actual pixel data. There was once a patch
> porposed to introduce a new enum value that only sets the infoframe and
> thus would allow userspace to pass through already limited range data.
> Shouldn't be hard to resurrect that if needed.

For the time being I try to keep the functionality of Broadcast RGB the same and just port it over to AMDGPU, but i
haven't looked into it in detail yet.

>
>> 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. :-)
> Here's an ugly one for i915:
>
>     (input RGB vs. YCbCr?)
> [FB] -> [YCbCr?] -> [YCbCr->RGB conversion     ] -> [plane blending] -> ...
>       |             [YCbCr color range/encoding] |
>       \ [RGB?] ----------------------------------/
>
>                                            (output RGB limited vs. RGB full vs. YCbCr?)
> ... -> [DEGAMMA_LUT] -> [CTM] -> [GAMMA_LUT] -> [YCbCr?] -> [RGB->YCbCr conversion      ] -> [to port]
>                                               |             [always BT.709/limited range]
>                                               \ [RGB?] -> ...
>
> ... -> [RGB passthrough             ] -> [to port]
>      | [Broadcast RGB=full or       ]
>      | [Broadcast RGB=auto + IT mode]
>      |
>      \ [RGB full->limited conversion] -> [to port]
>        [Broadcast RGB=limited or    ]
>        [Broadcast RGB=auto + CE mode]
>
> I guess having something like that in the docs would be nice. Not sure
> if there's a way to make something that looks decent for html/etc.
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Werner Sembach]

Am 19.05.21 um 15:49 schrieb Ville Syrjälä:
> On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
>> 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:
>>>>
>>>> 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.
>>
>> However, knowing what happened is going to be important for color
>> calibration auditing:
>> https://gitlab.freedesktop.org/wayland/weston/-/issues/467
>>
>> 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,
> Well, there could be dithering and whatnot also involved. So it's
> not super well specified atm either.
>
>> 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?
> It does indeed compress the actual pixel data. There was once a patch
> porposed to introduce a new enum value that only sets the infoframe and
> thus would allow userspace to pass through already limited range data.
> Shouldn't be hard to resurrect that if needed.

For the time being I try to keep the functionality of Broadcast RGB the same and just port it over to AMDGPU, but i
haven't looked into it in detail yet.

>
>> 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. :-)
> Here's an ugly one for i915:
>
>     (input RGB vs. YCbCr?)
> [FB] -> [YCbCr?] -> [YCbCr->RGB conversion     ] -> [plane blending] -> ...
>       |             [YCbCr color range/encoding] |
>       \ [RGB?] ----------------------------------/
>
>                                            (output RGB limited vs. RGB full vs. YCbCr?)
> ... -> [DEGAMMA_LUT] -> [CTM] -> [GAMMA_LUT] -> [YCbCr?] -> [RGB->YCbCr conversion      ] -> [to port]
>                                               |             [always BT.709/limited range]
>                                               \ [RGB?] -> ...
>
> ... -> [RGB passthrough             ] -> [to port]
>      | [Broadcast RGB=full or       ]
>      | [Broadcast RGB=auto + IT mode]
>      |
>      \ [RGB full->limited conversion] -> [to port]
>        [Broadcast RGB=limited or    ]
>        [Broadcast RGB=auto + CE mode]
>
> I guess having something like that in the docs would be nice. Not sure
> if there's a way to make something that looks decent for html/etc.
>

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 6475 bytes --]

Hi,

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
> 
> 
> Current State:
> 
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't
> know how other driver handle color management
> 
> - "max bpc", global setting applied by both i915 (only on dp i think?)
> and amdgpu. Default value is "8". For every resolution + frequency
> combination the highest possible even number between 6 and max_bpc is
> chosen. If the range doesn't contain a valid mode the resolution +
> frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10
> would work). Intel HDMI code always checks 8, 12, and 10 and does not
> check the max_bpc setting.
> 
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver
> (not amdgpu), overwrites the kernel chosen color range setting (full
> or limited). If I recall correctly Intel HDMI code defaults to full
> unless this property is set, Intel dp code tries to probe the monitor
> to find out what to use. amdgpu has no corresponding setting (I don't
> know how it's decided there).
> 
> - RGB pixel encoding can be forced by overloading a Monitors edid with
> one that tells the kernel that only RGB is possible. That doesn't work
> for YCbCr 4:4:4 however because of the edid specification. Forcing
> YCbCr 4:2:0 would theoretically also be possible this way. amdgpu has
> a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
> 
> 
> Proposed Solution:
> 
> 1. Add a new uAPI property "preferred pixel encoding", as a per port
>    setting.
> 
>     - An amdgpu specific implementation was already shared here:
>       https://gitlab.freedesktop.org/drm/amd/-/issues/476
> 
>     - It also writes back the actually used encoding if the one
>     	requested was not possible, overwriting the requested value in
>     	the process. I think it would be better to have this feedback
>     	channel as a different, read-only property.
> 
>     - Make this solution vendor agnostic by putting it in the
>     	drm_connector_state struct next do max_bpc
>     	https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654
>     	and add patches to amdgpu and i915 to respect this setting
> 
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a
>    vendor agnostic setting.
> 
>     - Imho the name is not very fitting, but it pops up in many
>     	tutorials throughout the web (some other opinions? how could a
>     	rename be handled?".
> 
>     - Also move it from Intel specific structs to the
>       drm_connector_state struct (please let me know if there is a
>       better place)
> 
> 3. Strive for full implementation of "max bpc"
> 
>     - I need to double check the Intel HDMI code.
> 
> 4. Add 3 feedback channels "active color depth", "active color range",
>    and "active pixel encoding" as vendor agnostic settings in the
>    drm_connector_state struct
> 
>     - Possible values are:
> 
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit,
>     	    12-bit, 14-bit, 16-bit (alternatively: an integer from -1
>     	    (unknown), 0 (undefined) to 16, let me know what would be
>     	    more suitable)
> 
>         - unknown, undefined, full, limited
> 
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420

I've started to implement this for the raspberrypi some time ago.

https://github.com/raspberrypi/linux/pull/4201

It's basically two properties: a bitmask of the available output pixel
encoding to report both what the display and the controller supports,
and one to actually set what the userspace wants to get enforced (and
that would return the active one when read).

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 6475 bytes --]

Hi,

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
> 
> 
> Current State:
> 
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't
> know how other driver handle color management
> 
> - "max bpc", global setting applied by both i915 (only on dp i think?)
> and amdgpu. Default value is "8". For every resolution + frequency
> combination the highest possible even number between 6 and max_bpc is
> chosen. If the range doesn't contain a valid mode the resolution +
> frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10
> would work). Intel HDMI code always checks 8, 12, and 10 and does not
> check the max_bpc setting.
> 
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver
> (not amdgpu), overwrites the kernel chosen color range setting (full
> or limited). If I recall correctly Intel HDMI code defaults to full
> unless this property is set, Intel dp code tries to probe the monitor
> to find out what to use. amdgpu has no corresponding setting (I don't
> know how it's decided there).
> 
> - RGB pixel encoding can be forced by overloading a Monitors edid with
> one that tells the kernel that only RGB is possible. That doesn't work
> for YCbCr 4:4:4 however because of the edid specification. Forcing
> YCbCr 4:2:0 would theoretically also be possible this way. amdgpu has
> a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
> 
> 
> Proposed Solution:
> 
> 1. Add a new uAPI property "preferred pixel encoding", as a per port
>    setting.
> 
>     - An amdgpu specific implementation was already shared here:
>       https://gitlab.freedesktop.org/drm/amd/-/issues/476
> 
>     - It also writes back the actually used encoding if the one
>     	requested was not possible, overwriting the requested value in
>     	the process. I think it would be better to have this feedback
>     	channel as a different, read-only property.
> 
>     - Make this solution vendor agnostic by putting it in the
>     	drm_connector_state struct next do max_bpc
>     	https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654
>     	and add patches to amdgpu and i915 to respect this setting
> 
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a
>    vendor agnostic setting.
> 
>     - Imho the name is not very fitting, but it pops up in many
>     	tutorials throughout the web (some other opinions? how could a
>     	rename be handled?".
> 
>     - Also move it from Intel specific structs to the
>       drm_connector_state struct (please let me know if there is a
>       better place)
> 
> 3. Strive for full implementation of "max bpc"
> 
>     - I need to double check the Intel HDMI code.
> 
> 4. Add 3 feedback channels "active color depth", "active color range",
>    and "active pixel encoding" as vendor agnostic settings in the
>    drm_connector_state struct
> 
>     - Possible values are:
> 
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit,
>     	    12-bit, 14-bit, 16-bit (alternatively: an integer from -1
>     	    (unknown), 0 (undefined) to 16, let me know what would be
>     	    more suitable)
> 
>         - unknown, undefined, full, limited
> 
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420

I've started to implement this for the raspberrypi some time ago.

https://github.com/raspberrypi/linux/pull/4201

It's basically two properties: a bitmask of the available output pixel
encoding to report both what the display and the controller supports,
and one to actually set what the userspace wants to get enforced (and
that would return the active one when read).

Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 6475 bytes --]

Hi,

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
> 
> 
> Current State:
> 
> I only know bits about the Intel i915 and AMD amdgpu driver. I don't
> know how other driver handle color management
> 
> - "max bpc", global setting applied by both i915 (only on dp i think?)
> and amdgpu. Default value is "8". For every resolution + frequency
> combination the highest possible even number between 6 and max_bpc is
> chosen. If the range doesn't contain a valid mode the resolution +
> frequency combination is discarded (but I guess that would be a very
> special edge case, if existent at all, when 6 doesn't work but 10
> would work). Intel HDMI code always checks 8, 12, and 10 and does not
> check the max_bpc setting.
> 
> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver
> (not amdgpu), overwrites the kernel chosen color range setting (full
> or limited). If I recall correctly Intel HDMI code defaults to full
> unless this property is set, Intel dp code tries to probe the monitor
> to find out what to use. amdgpu has no corresponding setting (I don't
> know how it's decided there).
> 
> - RGB pixel encoding can be forced by overloading a Monitors edid with
> one that tells the kernel that only RGB is possible. That doesn't work
> for YCbCr 4:4:4 however because of the edid specification. Forcing
> YCbCr 4:2:0 would theoretically also be possible this way. amdgpu has
> a debugfs switch "force_ycbcr_420" which makes the driver default to
> YCbCr 4:2:0 on all monitors if possible.
> 
> 
> Proposed Solution:
> 
> 1. Add a new uAPI property "preferred pixel encoding", as a per port
>    setting.
> 
>     - An amdgpu specific implementation was already shared here:
>       https://gitlab.freedesktop.org/drm/amd/-/issues/476
> 
>     - It also writes back the actually used encoding if the one
>     	requested was not possible, overwriting the requested value in
>     	the process. I think it would be better to have this feedback
>     	channel as a different, read-only property.
> 
>     - Make this solution vendor agnostic by putting it in the
>     	drm_connector_state struct next do max_bpc
>     	https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654
>     	and add patches to amdgpu and i915 to respect this setting
> 
> 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a
>    vendor agnostic setting.
> 
>     - Imho the name is not very fitting, but it pops up in many
>     	tutorials throughout the web (some other opinions? how could a
>     	rename be handled?".
> 
>     - Also move it from Intel specific structs to the
>       drm_connector_state struct (please let me know if there is a
>       better place)
> 
> 3. Strive for full implementation of "max bpc"
> 
>     - I need to double check the Intel HDMI code.
> 
> 4. Add 3 feedback channels "active color depth", "active color range",
>    and "active pixel encoding" as vendor agnostic settings in the
>    drm_connector_state struct
> 
>     - Possible values are:
> 
>         - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit,
>     	    12-bit, 14-bit, 16-bit (alternatively: an integer from -1
>     	    (unknown), 0 (undefined) to 16, let me know what would be
>     	    more suitable)
> 
>         - unknown, undefined, full, limited
> 
>         - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420

I've started to implement this for the raspberrypi some time ago.

https://github.com/raspberrypi/linux/pull/4201

It's basically two properties: a bitmask of the available output pixel
encoding to report both what the display and the controller supports,
and one to actually set what the userspace wants to get enforced (and
that would return the active one when read).

Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

On Mon, 7 Jun 2021 09:48:05 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

> I've started to implement this for the raspberrypi some time ago.
> 
> https://github.com/raspberrypi/linux/pull/4201
> 
> It's basically two properties: a bitmask of the available output pixel
> encoding to report both what the display and the controller supports,
> and one to actually set what the userspace wants to get enforced (and
> that would return the active one when read).

Hi Maxime,

I would like to point out that I think it is a bad design to create a
read/write property that returns not what was written to it. It can
cause headaches to userspace that wants to save and restore property
values it does not understand. Userspace would want to do that to
mitigate damage from switching to another KMS client and then back. The
other KMS client could change properties the first KMS client does not
understand, causing the first KMS client to show incorrectly after
switching back.

Please, consider whether this use-case will work before designing a
property where read-back may not necessarily return the written value.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 1157 bytes --]

On Mon, 7 Jun 2021 09:48:05 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

> I've started to implement this for the raspberrypi some time ago.
> 
> https://github.com/raspberrypi/linux/pull/4201
> 
> It's basically two properties: a bitmask of the available output pixel
> encoding to report both what the display and the controller supports,
> and one to actually set what the userspace wants to get enforced (and
> that would return the active one when read).

Hi Maxime,

I would like to point out that I think it is a bad design to create a
read/write property that returns not what was written to it. It can
cause headaches to userspace that wants to save and restore property
values it does not understand. Userspace would want to do that to
mitigate damage from switching to another KMS client and then back. The
other KMS client could change properties the first KMS client does not
understand, causing the first KMS client to show incorrectly after
switching back.

Please, consider whether this use-case will work before designing a
property where read-back may not necessarily return the written value.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 1157 bytes --]

On Mon, 7 Jun 2021 09:48:05 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

> I've started to implement this for the raspberrypi some time ago.
> 
> https://github.com/raspberrypi/linux/pull/4201
> 
> It's basically two properties: a bitmask of the available output pixel
> encoding to report both what the display and the controller supports,
> and one to actually set what the userspace wants to get enforced (and
> that would return the active one when read).

Hi Maxime,

I would like to point out that I think it is a bad design to create a
read/write property that returns not what was written to it. It can
cause headaches to userspace that wants to save and restore property
values it does not understand. Userspace would want to do that to
mitigate damage from switching to another KMS client and then back. The
other KMS client could change properties the first KMS client does not
understand, causing the first KMS client to show incorrectly after
switching back.

Please, consider whether this use-case will work before designing a
property where read-back may not necessarily return the written value.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Maxime Ripard]

Hi Pekka,

On Mon, Jun 07, 2021 at 11:06:32AM +0300, Pekka Paalanen wrote:
> On Mon, 7 Jun 2021 09:48:05 +0200
> Maxime Ripard <maxime@cerno.tech> wrote:
> 
> > I've started to implement this for the raspberrypi some time ago.
> > 
> > https://github.com/raspberrypi/linux/pull/4201
> > 
> > It's basically two properties: a bitmask of the available output pixel
> > encoding to report both what the display and the controller supports,
> > and one to actually set what the userspace wants to get enforced (and
> > that would return the active one when read).
> 
> Hi Maxime,
> 
> I would like to point out that I think it is a bad design to create a
> read/write property that returns not what was written to it. It can
> cause headaches to userspace that wants to save and restore property
> values it does not understand. Userspace would want to do that to
> mitigate damage from switching to another KMS client and then back. The
> other KMS client could change properties the first KMS client does not
> understand, causing the first KMS client to show incorrectly after
> switching back.
> 
> Please, consider whether this use-case will work before designing a
> property where read-back may not necessarily return the written value.

Thanks for bringing that up. I guess the work being done currently by
Werner and his active color format property addresses that concern :)

Maxime

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Maxime Ripard]

Hi Pekka,

On Mon, Jun 07, 2021 at 11:06:32AM +0300, Pekka Paalanen wrote:
> On Mon, 7 Jun 2021 09:48:05 +0200
> Maxime Ripard <maxime@cerno.tech> wrote:
> 
> > I've started to implement this for the raspberrypi some time ago.
> > 
> > https://github.com/raspberrypi/linux/pull/4201
> > 
> > It's basically two properties: a bitmask of the available output pixel
> > encoding to report both what the display and the controller supports,
> > and one to actually set what the userspace wants to get enforced (and
> > that would return the active one when read).
> 
> Hi Maxime,
> 
> I would like to point out that I think it is a bad design to create a
> read/write property that returns not what was written to it. It can
> cause headaches to userspace that wants to save and restore property
> values it does not understand. Userspace would want to do that to
> mitigate damage from switching to another KMS client and then back. The
> other KMS client could change properties the first KMS client does not
> understand, causing the first KMS client to show incorrectly after
> switching back.
> 
> Please, consider whether this use-case will work before designing a
> property where read-back may not necessarily return the written value.

Thanks for bringing that up. I guess the work being done currently by
Werner and his active color format property addresses that concern :)

Maxime
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Maxime Ripard]

Hi Pekka,

On Mon, Jun 07, 2021 at 11:06:32AM +0300, Pekka Paalanen wrote:
> On Mon, 7 Jun 2021 09:48:05 +0200
> Maxime Ripard <maxime@cerno.tech> wrote:
> 
> > I've started to implement this for the raspberrypi some time ago.
> > 
> > https://github.com/raspberrypi/linux/pull/4201
> > 
> > It's basically two properties: a bitmask of the available output pixel
> > encoding to report both what the display and the controller supports,
> > and one to actually set what the userspace wants to get enforced (and
> > that would return the active one when read).
> 
> Hi Maxime,
> 
> I would like to point out that I think it is a bad design to create a
> read/write property that returns not what was written to it. It can
> cause headaches to userspace that wants to save and restore property
> values it does not understand. Userspace would want to do that to
> mitigate damage from switching to another KMS client and then back. The
> other KMS client could change properties the first KMS client does not
> understand, causing the first KMS client to show incorrectly after
> switching back.
> 
> Please, consider whether this use-case will work before designing a
> property where read-back may not necessarily return the written value.

Thanks for bringing that up. I guess the work being done currently by
Werner and his active color format property addresses that concern :)

Maxime
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Werner Sembach]

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:
>>>
>>> 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.

Thanks

>
> However, knowing what happened is going to be important for color
> calibration auditing:
> https://gitlab.freedesktop.org/wayland/weston/-/issues/467
>
> 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

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Werner Sembach]

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:
>>>
>>> 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.

Thanks

>
> However, knowing what happened is going to be important for color
> calibration auditing:
> https://gitlab.freedesktop.org/wayland/weston/-/issues/467
>
> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Werner Sembach]

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:
>>>
>>> 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.

Thanks

>
> However, knowing what happened is going to be important for color
> calibration auditing:
> https://gitlab.freedesktop.org/wayland/weston/-/issues/467
>
> 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
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 4071 bytes --]

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:
> >>>
> >>> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 4071 bytes --]

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:
> >>>
> >>> 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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: New uAPI for color management proposal and feedback request

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 4071 bytes --]

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:
> >>>
> >>> 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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx