On Wed, Jun 1, 2022 at 4:06 PM Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Wed, Jun 01, 2022 at 10:21:26AM +0300, Pekka Paalanen wrote:
On Tue, 31 May 2022 20:37:31 +0300 Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Wed, May 25, 2022 at 01:36:47PM +0300, Pekka Paalanen wrote:
On Wed, 25 May 2022 09:23:51 +0000 Simon Ser contact@emersion.fr wrote:
On Wednesday, May 25th, 2022 at 10:35, Michel Dänzer michel.daenzer@mailbox.org wrote:
> Mind that "max bpc" is always in auto. It's only an upper limit, with > the assumption that the driver can choose less.
It seems to me like the "max bpc" property is just kind of bad API, and trying to tweak it to cater to more use cases as we discover them will take us down a rabbit hole. It seems better to replace it with new properties which allow user space to determine the current effective bpc and to explicitly control it.
+1, this sounds much more robust, and allows better control by user-space. User-space needs to have fallback logic for other state as well anyways. If the combinatorial explosion is too much, we should think about optimizing the KMS implementation, or improve the uAPI.
+1 as well, with some recommendations added and the running off to the sunset:
Use two separate KMS properties for reporting current vs. programming desired. The KMS property reporting the current value must be read-only (immutable). This preserves the difference between what userspace wanted and what it got, making it possible to read back both without confusing them. It also allows preserving driver behaviour
I don't see much real point in a property to report the current bpc. That can't be used to do anything atomically. So I suppose plymouth would be the only user.
Hi Ville,
I think also professional color managed display servers would need it.
If they detect that the link bpc is no longer the same as it was when the monitor was profiled, the profile will need to be re-verified by measuring the monitor again.
See "Color calibration auditing system" notes in https://gitlab.freedesktop.org/wayland/weston/-/issues/467 description.
So IMO if someone really need explicit control over this then we should just expose properties to set things explicitly. So we'd need at least props for the actual bpc and some kind of color encoding property (RGB/YCbCr 4:4:4/4:2:2:/4:2:0, etc.). And someone would really need to figure out how DSC would interact with those.
I believe there still must be "auto" setting for bpc, and a separate feedback property, so that userspace can use "auto" to see what it can get without doing thousands of TEST_ONLY commits plus a few "link status" failure handlings in order to find a working configuration (I'm assuming we have many more properties than just "max bpc" to figure out). After "auto" has told userspace what actually works without blind trial and error, then userspace can program than value explicitly to make sure it doesn't change accidentally in the future.
Yeah we need "auto", but IMO mainly just to keep the current userspace working. Using that to probe what's possible doesn't sound particularly workable since you can't use it with TEST_ONLY commits. Also change to some other property could still cause the whole thing to fail after the max bpc has been probed so not sure it really buys you anything.
Why would we need "auto" to not break user space?
I agree though that a single property which accurately reflects the "bpc" should be sufficient. If you want to set bpc to a certain value you probably also want to do the same for RGB/YUV subsampling and DSC which makes selecting a working mode without TEST_ONLY commits impractical.
The combinatorial explosion is a real issue but to me it seems possible to aggregate some properties into a group without dependencies on other properties. For example we could have a "mode" group which contains "MODE_ID", "bpc", pixel format/subsampling and DSC properties in the future. If the atomic test commit then returns a bitmask of the groups which failed you can considerably cut down on the combinatorial problem.
What's DSC?
Compression.
Now that you mentioned some kind of color encoding property (I assume you referred mostly to the sub-sampling aspect), how does the connector property "Colorspace" factor in?
The "Colorspace" property just changes what we report to the display via infoframes/MSA/SDP. It does not cause the display hardware to do any colorspace conversion/etc.
To actually force the display hardware to do the desired conversion we need some new properties. ATM the only automagic conversion that can happen (at least with i915) is the RGB 4:4:4->YCbCr 4:2:0 fallback, which is needed on some displays to get 4k+ modes to work at all.
Having control over this and compression would also help with defining bpc. We could say bpc refers to the minimum bpc of all components for RGB and the bpc of the luminance channel for YUV, all with compression disabled. If user space turns on subsampling and compression it understands the impacts on the effective bit depth.
Anyway, the Colorspace property is literally impossible to set correctly because the kernel can just send either RGB or YUV without any way for user space to figure out which it is but it's responsible for sending the corresponding Colorspace. If I set the colorspace with the wrong pixel format the colors are, as expected, completely broken and there is nothing I can do but hope that it works by accident.
The enum values (which are not documented in KMS docs, btw.) are tuples of color space + color model, e.g. on Intel:
"Colorspace": enum {Default, SMPTE_170M_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, DCI-P3_RGB_Theater}
The accepted values are just what the CTA-861/DP specs allow us to transmit in he infoframe/SDP/MSA.
Reading the KMS docs from https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#standard-connector-p... they say:
Basically the expectation from userspace is:
Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sinkcolorspace
Set this new property to let the sink know what it convertedthe CRTC output to.
This property is just to inform sink what colorspace sourceis trying to drive.
However, where does userspace program the actual conversion from RGB to NNN? Is it expected to be embedded in CTM?
Or does setting "Colorspace" imply some additional automatic conversion? If so, where does it happen and how is it chosen?
For just the plymouth case I guess the easiest thing would be to just clamp "max bpc" to the current value. The problem with that is that we'd potentially break existing userspace. Eg. I don't think the modesetting ddx or perhaps even most of the wayland compositors set "max bpc" at all. So we'd need to roll out a bunch of userspace updates first. And the "current bpc" prop idea would also have this same problem since plymouth would just clamp "max bpc" based on the current bpc before the real userspace starts.
True, but I believe once color management spreads through Wayland, so will KMS clients also learn to set it.
Sure. But my point is that if we want to change how the "max bpc" works I think we need to roll out the userspace stuff first so that we at least can tell the user "please update you userspace to release x" when they hit the regression.
Shouldn't we just change "max bpc" to always be the maximum by default? This doesn't break any user space but also doesn't solve the plymouth issue. For that we would then use the "bpc" property which always reflects the actual value. Plymouth would then set "bpc" to max(current bpc, 8) and leave "max bpc" at maximum.
-- Ville Syrjälä Intel