On Mon, 10 May 2021 17:47:01 -0400 Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Fri, May 7, 2021 at 3:27 PM Werner Sembach <wse@xxxxxxxxxxxxxxxxxxx> wrote: > > > > xrandr --prop and other userspace info tools have currently no way of > > telling which color configuration is used on HDMI and DP ports. > > > > The ongoing transsition from HDMI 1.4 to 2.0 and the different bandwidth > > requirements of YCbCr 4:2:0 and RGB color format raise different > > incompatibilities. Having these configuration information readily > > available is a useful tool in debuging washed out colors, color artefacts > > on small fonts and missing refreshrate options. > > I think we would ideally want these as generic connector properties > rather than AMD specific ones since they are not really AMD specific. > I believe there is already a generic drm property (max_bpc) for the > color depth. At this point, I think having a generic RGB vs YCbCr > property would make sense. I'm not sure about the color space. Hi, I believe that userspace will definitely want to know what exactly is going on on the monitor cable, so I think exposing more information is good, but I agree that it needs to be done with generic KMS properties as much as possible. Userspace is not going to bother having explicit code for driver-specific properties. I think a major use case will be Wayland color management, where a Wayland compositor will want to make sure that the video signal parameters have not changed since the monitor was last measured (profiled). If the signal configuration is different, the measured color profile may be invalid and therefore the end user needs to be warned. See some ideas in https://gitlab.freedesktop.org/wayland/weston/-/issues/467 under the heading "Color calibration auditing system". About the color space: is that something a kernel driver will decide on its own? I mean in the same sense as the driver will negotiate HDMI/DP link parameters, perhaps falling back to smaller requirements if higher requirements signal does not seem to work. We only need readback properties for things that generic userspace won't or cannot control explicitly, e.g. because the kernel driver has room to make a choice rather than fail. Thanks, pq
Attachment:
pgp2pF94q64Wu.pgp
Description: OpenPGP digital signature
