Re: New uAPI for color management proposal and feedback request v2
On Tue, 3 Aug 2021 11:38:19 +0200 Werner Sembach wrote: > Greetings, > > Original proposal: > https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg62387.html > > Abstract: Add "preferred color format", "active color format", "active bpc", > and "active Broadcast RGB" drm properties, > to control color information send to the monitor. > > It seems that the "preferred-" properties is not what is actually the most > useful for the userspace devs. > > Preferable (Note: with only a sample size of 2 people) would be a "force > color format" property. If the color format is > not available for the current Monitor and GPU combo. the TEST_ONLY check > should fail and the property should not be setable. > > This however opens another problem: When a Monitor is disconnected and a new > one is connected, the drm properties do not > get resetted. So if the old monitor did allow to set for example ycbcr420, > but the new monitor does not support this > color format at all, it will stay permanently black until the drm property is > set to a correct value by hand. This is > not an expected behavior imho. > > So a discussion questions: Does it make sense that connector properties are > keep for different Monitors? > > If no: On connecting a new Monitor all atomic drm properties should be reset > to a default value. > > I have an idea how this could be implemented (correct me if i'm wrong): When > an atomic property is attached it get > assigned an inital value. But if I understood the docu correctly, this value > is ignored because atomic properties use > the getter and setter methods when their values are read or written. My > implementation suggestion would be to iterate > over all attached atomic properties once a new monitor is connected and reset > them to this initial value, which should > be unchanged since initialization? This assumes that besides the initial > value being unused it's still a sane default > for all drivers. > > Kind Regards, > > Werner Sembach > Hi Werner, I just wanted to say that I appreciate the effort and something like these are things I would likely want to use some day in Weston, but currently I can't spend time on this since it's still so far in the future for me. I also feel that I've said what I can without spending a significant amount of time thinking how it should actually work. The same goes with the thing pointed out by Sebastian, the KMS property reset idea. Since I can't really work on it now, I'll stop shouting about it and wait for problems to arise in the wild and see where that leads. (Probably just patching the KMS client of the day to set a couple more KMS properties.) Thanks, pq pgpGBTt9yDqNA.pgp Description: OpenPGP digital signature
New uAPI for color management proposal and feedback request v2
Greetings, Original proposal: https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg62387.html Abstract: Add "preferred color format", "active color format", "active bpc", and "active Broadcast RGB" drm properties, to control color information send to the monitor. It seems that the "preferred-" properties is not what is actually the most useful for the userspace devs. Preferable (Note: with only a sample size of 2 people) would be a "force color format" property. If the color format is not available for the current Monitor and GPU combo. the TEST_ONLY check should fail and the property should not be setable. This however opens another problem: When a Monitor is disconnected and a new one is connected, the drm properties do not get resetted. So if the old monitor did allow to set for example ycbcr420, but the new monitor does not support this color format at all, it will stay permanently black until the drm property is set to a correct value by hand. This is not an expected behavior imho. So a discussion questions: Does it make sense that connector properties are keep for different Monitors? If no: On connecting a new Monitor all atomic drm properties should be reset to a default value. I have an idea how this could be implemented (correct me if i'm wrong): When an atomic property is attached it get assigned an inital value. But if I understood the docu correctly, this value is ignored because atomic properties use the getter and setter methods when their values are read or written. My implementation suggestion would be to iterate over all attached atomic properties once a new monitor is connected and reset them to this initial value, which should be unchanged since initialization? This assumes that besides the initial value being unused it's still a sane default for all drivers. Kind Regards, Werner Sembach
Re: New uAPI for color management proposal and feedback request
On Tue, 22 Jun 2021 19:06:43 +0200 Werner Sembach wrote: > Am 19.05.21 um 11:34 schrieb Pekka Paalanen: > > On Wed, 12 May 2021 16:04:16 +0300 > > Ville Syrjälä wrote: > > > >> On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: > >>> Hello, > >>> > >>> In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm > >>> properties I propose 4 new properties: > >>> "preferred pixel encoding", "active color depth", "active color range", > >>> and "active pixel encoding" > >>> > >>> > >>> Motivation: > >>> > >>> Current monitors have a variety pixel encodings available: RGB, YCbCr > >>> 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0. > >>> > >>> In addition they might be full or limited RGB range and the monitors > >>> accept different bit depths. > >>> > >>> Currently the kernel driver for AMD and Intel GPUs automatically > >>> configure the color settings automatically with little > >>> to no influence of the user. However there are several real world > >>> scenarios where the user might disagree with the > >>> default chosen by the drivers and wants to set his or her own preference. > >>> > >>> Some examples: > >>> > >>> 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color > >>> information, some screens might look better on one > >>> than the other because of bad internal conversion. The driver currently > >>> however has a fixed default that is chosen if > >>> available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change > >>> this currently is by editing and overloading > >>> the edid reported by the monitor to the kernel. > >>> > >>> 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some > >>> hardware might report that it supports the higher > >>> port clock, but because of bad shielding on the PC, the cable, or the > >>> monitor the screen cuts out every few seconds when > >>> RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work > >>> fine without changing hardware. The drivers > >>> currently however always default to the "best available" option even if > >>> it might be broken. > >>> > >>> 3. Some screens natively only supporting 8-bit color, simulate 10-Bit > >>> color by rapidly switching between 2 adjacent > >>> colors. They advertise themselves to the kernel as 10-bit monitors but > >>> the user might not like the "fake" 10-bit effect > >>> and prefer running at the native 8-bit per color. > >>> > >>> 4. Some screens are falsely classified as full RGB range wile they > >>> actually use limited RGB range. This results in > >>> washed out colors in dark and bright scenes. A user override can be > >>> helpful to manually fix this issue when it occurs. > >>> > >>> There already exist several requests, discussion, and patches regarding > >>> the thematic: > >>> > >>> - 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 pgpINH8KZtMlY.pgp Description: OpenPGP digital signature ___ 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
Am 19.05.21 um 11:34 schrieb Pekka Paalanen: > On Wed, 12 May 2021 16:04:16 +0300 > Ville Syrjälä wrote: > >> On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: >>> Hello, >>> >>> In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm >>> properties I propose 4 new properties: >>> "preferred pixel encoding", "active color depth", "active color range", and >>> "active pixel encoding" >>> >>> >>> Motivation: >>> >>> Current monitors have a variety pixel encodings available: RGB, YCbCr >>> 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0. >>> >>> In addition they might be full or limited RGB range and the monitors accept >>> different bit depths. >>> >>> Currently the kernel driver for AMD and Intel GPUs automatically configure >>> the color settings automatically with little >>> to no influence of the user. However there are several real world scenarios >>> where the user might disagree with the >>> default chosen by the drivers and wants to set his or her own preference. >>> >>> Some examples: >>> >>> 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color >>> information, some screens might look better on one >>> than the other because of bad internal conversion. The driver currently >>> however has a fixed default that is chosen if >>> available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change >>> this currently is by editing and overloading >>> the edid reported by the monitor to the kernel. >>> >>> 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some >>> hardware might report that it supports the higher >>> port clock, but because of bad shielding on the PC, the cable, or the >>> monitor the screen cuts out every few seconds when >>> RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine >>> without changing hardware. The drivers >>> currently however always default to the "best available" option even if it >>> might be broken. >>> >>> 3. Some screens natively only supporting 8-bit color, simulate 10-Bit color >>> by rapidly switching between 2 adjacent >>> colors. They advertise themselves to the kernel as 10-bit monitors but the >>> user might not like the "fake" 10-bit effect >>> and prefer running at the native 8-bit per color. >>> >>> 4. Some screens are falsely classified as full RGB range wile they actually >>> use limited RGB range. This results in >>> washed out colors in dark and bright scenes. A user override can be helpful >>> to manually fix this issue when it occurs. >>> >>> There already exist several requests, discussion, and patches regarding the >>> thematic: >>> >>> - 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
Re: New uAPI for color management proposal and feedback request
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 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
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
Re: New uAPI for color management proposal and feedback request
On Mon, 7 Jun 2021 09:48:05 +0200 Maxime Ripard 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 pgpCx8bToZ0dn.pgp Description: OpenPGP digital signature ___ 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
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ä 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
Re: New uAPI for color management proposal and feedback request
Am 12.05.21 um 19:59 schrieb Alex Deucher: > On Wed, May 12, 2021 at 9:04 AM Ville Syrjälä > wrote: >> On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: >>> Hello, >>> >>> In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm >>> properties I propose 4 new properties: >>> "preferred pixel encoding", "active color depth", "active color range", and >>> "active pixel encoding" >>> >>> >>> Motivation: >>> >>> Current monitors have a variety pixel encodings available: RGB, YCbCr >>> 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0. >>> >>> In addition they might be full or limited RGB range and the monitors accept >>> different bit depths. >>> >>> Currently the kernel driver for AMD and Intel GPUs automatically configure >>> the color settings automatically with little >>> to no influence of the user. However there are several real world scenarios >>> where the user might disagree with the >>> default chosen by the drivers and wants to set his or her own preference. >>> >>> Some examples: >>> >>> 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color >>> information, some screens might look better on one >>> than the other because of bad internal conversion. The driver currently >>> however has a fixed default that is chosen if >>> available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change >>> this currently is by editing and overloading >>> the edid reported by the monitor to the kernel. >>> >>> 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some >>> hardware might report that it supports the higher >>> port clock, but because of bad shielding on the PC, the cable, or the >>> monitor the screen cuts out every few seconds when >>> RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine >>> without changing hardware. The drivers >>> currently however always default to the "best available" option even if it >>> might be broken. >>> >>> 3. Some screens natively only supporting 8-bit color, simulate 10-Bit color >>> by rapidly switching between 2 adjacent >>> colors. They advertise themselves to the kernel as 10-bit monitors but the >>> user might not like the "fake" 10-bit effect >>> and prefer running at the native 8-bit per color. >>> >>> 4. Some screens are falsely classified as full RGB range wile they actually >>> use limited RGB range. This results in >>> washed out colors in dark and bright scenes. A user override can be helpful >>> to manually fix this issue when it occurs. >>> >>> There already exist several requests, discussion, and patches regarding the >>> thematic: >>> >>> - 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
Re: New uAPI for color management proposal and feedback request
On Wed, 19 May 2021 16:49:35 +0300 Ville Syrjälä 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ä 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
Re: New uAPI for color management proposal and feedback request
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ä 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
Re: New uAPI for color management proposal and feedback request
On Wed, 12 May 2021 16:04:16 +0300 Ville Syrjälä wrote: > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: > > Hello, > > > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm > > properties I propose 4 new properties: > > "preferred pixel encoding", "active color depth", "active color range", and > > "active pixel encoding" > > > > > > Motivation: > > > > Current monitors have a variety pixel encodings available: RGB, YCbCr > > 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0. > > > > In addition they might be full or limited RGB range and the monitors accept > > different bit depths. > > > > Currently the kernel driver for AMD and Intel GPUs automatically configure > > the color settings automatically with little > > to no influence of the user. However there are several real world scenarios > > where the user might disagree with the > > default chosen by the drivers and wants to set his or her own preference. > > > > Some examples: > > > > 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color > > information, some screens might look better on one > > than the other because of bad internal conversion. The driver currently > > however has a fixed default that is chosen if > > available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change > > this currently is by editing and overloading > > the edid reported by the monitor to the kernel. > > > > 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some > > hardware might report that it supports the higher > > port clock, but because of bad shielding on the PC, the cable, or the > > monitor the screen cuts out every few seconds when > > RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine > > without changing hardware. The drivers > > currently however always default to the "best available" option even if it > > might be broken. > > > > 3. Some screens natively only supporting 8-bit color, simulate 10-Bit color > > by rapidly switching between 2 adjacent > > colors. They advertise themselves to the kernel as 10-bit monitors but the > > user might not like the "fake" 10-bit effect > > and prefer running at the native 8-bit per color. > > > > 4. Some screens are falsely classified as full RGB range wile they actually > > use limited RGB range. This results in > > washed out colors in dark and bright scenes. A user override can be helpful > > to manually fix this issue when it occurs. > > > > There already exist several requests, discussion, and patches regarding the > > thematic: > > > > - 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
Re: New uAPI for color management proposal and feedback request
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 >
Re: New uAPI for color management proposal and feedback request
On Wed, May 12, 2021 at 9:04 AM Ville Syrjälä wrote: > > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: > > Hello, > > > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm > > properties I propose 4 new properties: > > "preferred pixel encoding", "active color depth", "active color range", and > > "active pixel encoding" > > > > > > Motivation: > > > > Current monitors have a variety pixel encodings available: RGB, YCbCr > > 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0. > > > > In addition they might be full or limited RGB range and the monitors accept > > different bit depths. > > > > Currently the kernel driver for AMD and Intel GPUs automatically configure > > the color settings automatically with little > > to no influence of the user. However there are several real world scenarios > > where the user might disagree with the > > default chosen by the drivers and wants to set his or her own preference. > > > > Some examples: > > > > 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color > > information, some screens might look better on one > > than the other because of bad internal conversion. The driver currently > > however has a fixed default that is chosen if > > available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change > > this currently is by editing and overloading > > the edid reported by the monitor to the kernel. > > > > 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some > > hardware might report that it supports the higher > > port clock, but because of bad shielding on the PC, the cable, or the > > monitor the screen cuts out every few seconds when > > RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine > > without changing hardware. The drivers > > currently however always default to the "best available" option even if it > > might be broken. > > > > 3. Some screens natively only supporting 8-bit color, simulate 10-Bit color > > by rapidly switching between 2 adjacent > > colors. They advertise themselves to the kernel as 10-bit monitors but the > > user might not like the "fake" 10-bit effect > > and prefer running at the native 8-bit per color. > > > > 4. Some screens are falsely classified as full RGB range wile they actually > > use limited RGB range. This results in > > washed out colors in dark and bright scenes. A user override can be helpful > > to manually fix this issue when it occurs. > > > > There already exist several requests, discussion, and patches regarding the > > thematic: > > > > - 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
Re: New uAPI for color management proposal and feedback request
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 >
Re: New uAPI for color management proposal and feedback request
On Wednesday, May 12th, 2021 at 3:04 PM, Ville Syrjälä 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
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
New uAPI for color management proposal and feedback request
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
