| Message ID | 20210608174320.37429-3-wse@tuxedocomputers.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add "activ bpc" and "active color format" drm property | expand |
On Tue, 8 Jun 2021 19:43:15 +0200 Werner Sembach <wse@tuxedocomputers.com> wrote: > Add a new general drm property "active bpc" which can be used by graphic drivers > to report the applied bit depth per pixel back to userspace. > > While "max bpc" can be used to change the color depth, there was no way to check > which one actually got used. While in theory the driver chooses the best/highest > color depth within the max bpc setting a user might not be fully aware what his > hardware is or isn't capable off. This is meant as a quick way to double check > the setup. > > In the future, automatic color calibration for screens might also depend on this > information being available. > > Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> > --- > drivers/gpu/drm/drm_atomic_uapi.c | 2 ++ > drivers/gpu/drm/drm_connector.c | 41 +++++++++++++++++++++++++++++++ > include/drm/drm_connector.h | 15 +++++++++++ > 3 files changed, 58 insertions(+) > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c > index 268bb69c2e2f..7ae4e40936b5 100644 > --- a/drivers/gpu/drm/drm_atomic_uapi.c > +++ b/drivers/gpu/drm/drm_atomic_uapi.c > @@ -873,6 +873,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector, > *val = 0; > } else if (property == connector->max_bpc_property) { > *val = state->max_requested_bpc; > + } else if (property == connector->active_bpc_property) { > + *val = state->active_bpc; > } else if (connector->funcs->atomic_get_property) { > return connector->funcs->atomic_get_property(connector, > state, property, val); > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index 7631f76e7f34..c0c3c09bfed0 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1195,6 +1195,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = { > * drm_connector_attach_max_bpc_property() to create and attach the > * property to the connector during initialization. > * > + * active bpc: > + * This read-only range property tells userspace the pixel color bit depth > + * actually used by the hardware display engine on "the cable" on a > + * connector. The chosen value depends on hardware capabilities, both > + * display engine and connected monitor, and the "max bpc" property. > + * Drivers shall use drm_connector_attach_active_bpc_property() to install > + * this property. > + * This description is now clear to me, but I wonder, is it also how others understand it wrt. dithering? Dithering done on monitor is irrelevant, because we are talking about "on the cable" pixels. But since we are talking about "on the cable" pixels, also dithering done by the display engine must not factor in. Should the dithering done by display engine result in higher "active bpc" number than what is actually transmitted on the cable? I cannot guess what userspace would want exactly. I think the strict "on the cable" interpretation is a safe bet, because it then gives a lower limit on observed bpc. Dithering settings should be exposed with other KMS properties, so userspace can factor those in. But to be absolutely sure, we'd have to ask some color management experts. Cc'ing Mario in case he has an opinion. Since "active bpc" is related to "max bpc", the both should follow the same definition. Do they do that now? Maybe a clarifying note about interaction with dithering would still be good to have here. I recall reading some comments from you about having problems with making this immutable. Is it properly immutable now? That is, drm_info reports the property as "(immutable)". https://github.com/ascent12/drm_info If we are not sure if DSC could result in lower observed bpc than "active bpc", then DSC state would need to be exposed as a KMS property too, with a note that it invalidates what "active bpc" shows. Or maybe "active bpc" should be "unknown" in that case? Thanks, pq > * Connectors also have one standardized atomic property: > * > * CRTC_ID: > @@ -2150,6 +2158,39 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector, > } > EXPORT_SYMBOL(drm_connector_attach_max_bpc_property); > > +/** > + * drm_connector_attach_active_bpc_property - attach "active bpc" property > + * @connector: connector to attach active bpc property on. > + * @min: The minimum bit depth supported by the connector. > + * @max: The maximum bit depth supported by the connector. > + * > + * This is used to check the applied bit depth on a connector. > + * > + * Returns: > + * Zero on success, negative errno on failure. > + */ > +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, > + int min, int max) > +{ > + struct drm_device *dev = connector->dev; > + struct drm_property *prop; > + > + prop = connector->active_bpc_property; > + if (!prop) { > + prop = drm_property_create_range(dev, 0, "active bpc", min, max); > + if (!prop) > + return -ENOMEM; > + > + connector->active_bpc_property = prop; > + } > + > + drm_object_attach_property(&connector->base, prop, 0); > + connector->state->active_bpc = 0; > + > + return 0; > +} > +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property); > + > /** > * drm_connector_set_vrr_capable_property - sets the variable refresh rate > * capable property for a connector > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h > index 1922b278ffad..c58cba2b6afe 100644 > --- a/include/drm/drm_connector.h > +++ b/include/drm/drm_connector.h > @@ -781,6 +781,13 @@ struct drm_connector_state { > */ > u8 max_bpc; > > + /** > + * @active_bpc: Read only property set by the GPU driver to the actually > + * applied bit depth of the pixels after evaluating all hardware > + * limitations. > + */ > + u8 active_bpc; > + > /** > * @hdr_output_metadata: > * DRM blob property for HDR output metadata > @@ -1380,6 +1387,12 @@ struct drm_connector { > */ > struct drm_property *max_bpc_property; > > + /** > + * @active_bpc_property: Default connector property for the active bpc > + * to be driven out of the connector. > + */ > + struct drm_property *active_bpc_property; > + > #define DRM_CONNECTOR_POLL_HPD (1 << 0) > #define DRM_CONNECTOR_POLL_CONNECT (1 << 1) > #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2) > @@ -1698,6 +1711,8 @@ int drm_connector_set_panel_orientation_with_quirk( > int width, int height); > int drm_connector_attach_max_bpc_property(struct drm_connector *connector, > int min, int max); > +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, > + int min, int max); > > /** > * struct drm_tile_group - Tile group metadata
On Thu, Jun 10, 2021 at 9:55 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > On Tue, 8 Jun 2021 19:43:15 +0200 > Werner Sembach <wse@tuxedocomputers.com> wrote: > > > Add a new general drm property "active bpc" which can be used by graphic drivers > > to report the applied bit depth per pixel back to userspace. > > Maybe "bit depth per pixel" -> "bit depth per pixel color component" for slightly more clarity? > > While "max bpc" can be used to change the color depth, there was no way to check > > which one actually got used. While in theory the driver chooses the best/highest > > color depth within the max bpc setting a user might not be fully aware what his > > hardware is or isn't capable off. This is meant as a quick way to double check > > the setup. > > > > In the future, automatic color calibration for screens might also depend on this > > information being available. > > > > Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> > > --- > > drivers/gpu/drm/drm_atomic_uapi.c | 2 ++ > > drivers/gpu/drm/drm_connector.c | 41 +++++++++++++++++++++++++++++++ > > include/drm/drm_connector.h | 15 +++++++++++ > > 3 files changed, 58 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c > > index 268bb69c2e2f..7ae4e40936b5 100644 > > --- a/drivers/gpu/drm/drm_atomic_uapi.c > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c > > @@ -873,6 +873,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector, > > *val = 0; > > } else if (property == connector->max_bpc_property) { > > *val = state->max_requested_bpc; > > + } else if (property == connector->active_bpc_property) { > > + *val = state->active_bpc; > > } else if (connector->funcs->atomic_get_property) { > > return connector->funcs->atomic_get_property(connector, > > state, property, val); > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > > index 7631f76e7f34..c0c3c09bfed0 100644 > > --- a/drivers/gpu/drm/drm_connector.c > > +++ b/drivers/gpu/drm/drm_connector.c > > @@ -1195,6 +1195,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = { > > * drm_connector_attach_max_bpc_property() to create and attach the > > * property to the connector during initialization. > > * > > + * active bpc: > > + * This read-only range property tells userspace the pixel color bit depth > > + * actually used by the hardware display engine on "the cable" on a > > + * connector. The chosen value depends on hardware capabilities, both > > + * display engine and connected monitor, and the "max bpc" property. > > + * Drivers shall use drm_connector_attach_active_bpc_property() to install > > + * this property. > > + * > > This description is now clear to me, but I wonder, is it also how > others understand it wrt. dithering? > > Dithering done on monitor is irrelevant, because we are talking about > "on the cable" pixels. But since we are talking about "on the cable" > pixels, also dithering done by the display engine must not factor in. > Should the dithering done by display engine result in higher "active > bpc" number than what is actually transmitted on the cable? > > I cannot guess what userspace would want exactly. I think the > strict "on the cable" interpretation is a safe bet, because it then > gives a lower limit on observed bpc. Dithering settings should be > exposed with other KMS properties, so userspace can factor those in. > But to be absolutely sure, we'd have to ask some color management > experts. > > Cc'ing Mario in case he has an opinion. > Thanks. I like this a lot, in fact such a connector property was on my todo list / wish list for something like that! I agree with the "active bpc" definition here in this patch and Pekka's comments. I want what goes out over the cable, not including any effects of dithering. At least AMD's amdpu-kms driver exposes "active bpc" already as a per-connector property in debugfs, and i use reported output from there a lot to debug problems with respect to HDR display or high color precision output, and to verify i'm not fooling myself wrt. what goes out, compared to what dithering may "fake" on top of it. Software like mine would greatly benefit from getting this directly off the connector, ie. as a RandR output property, just like with "max bpc", as mapping X11 output names to driver output names is a guessing game, directing regular users to those debugfs files is tedious and error prone, and many regular users don't have root permissions anyway. Sometimes one wants to prioritize "active bpc" over resolution or refresh rate, and especially on now more common HDR displays, and actual bit depth also changes depending on bandwidth requirements vs. availability, and how well DP link training went with a flaky or loose cable, like only getting 10 bpc for HDR-10 when running on less than maximum resolution or refresh rate, and the cable "just right". This can be very puzzling without actual feedback over true "active bpc". It would also be very beneficial to also have reporting and control over gpu dithering state via a read/write property. Some drivers like nouveau-kms have that, and i think some older non-atomic amd drivers had it at some point in time iirc, which was useful, also for debugging of dithering induced issues, when one wants to pass-through a 8 bpc framebuffer unmodified to special display equipment, and dithering silently kicked in and is messing things up. And a read only property for DSC active would be good to account for the future. > Since "active bpc" is related to "max bpc", the both should follow the > same definition. Do they do that now? > > Maybe a clarifying note about interaction with dithering would still be > good to have here. > +1 > > I recall reading some comments from you about having problems with > making this immutable. Is it properly immutable now? > > That is, drm_info reports the property as "(immutable)". > https://github.com/ascent12/drm_info > > If we are not sure if DSC could result in lower observed bpc than > "active bpc", then DSC state would need to be exposed as a KMS property > too, with a note that it invalidates what "active bpc" shows. Or maybe > "active bpc" should be "unknown" in that case? > Yes. Or could we have some way of disabling DSC per connector in the future? I'm not familiar with current implementations, but i'd very much would like to have a selectable tradeoff if i want a "pure" video signal and maybe not get some high resolution / refresh rate modes on low-bandwidth cables, or if i want max resolution/refresh but some lossy perceptual compression. thanks, -mario > > Thanks, > pq > > > * Connectors also have one standardized atomic property: > > * > > * CRTC_ID: > > @@ -2150,6 +2158,39 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector, > > } > > EXPORT_SYMBOL(drm_connector_attach_max_bpc_property); > > > > +/** > > + * drm_connector_attach_active_bpc_property - attach "active bpc" property > > + * @connector: connector to attach active bpc property on. > > + * @min: The minimum bit depth supported by the connector. > > + * @max: The maximum bit depth supported by the connector. > > + * > > + * This is used to check the applied bit depth on a connector. > > + * > > + * Returns: > > + * Zero on success, negative errno on failure. > > + */ > > +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, > > + int min, int max) > > +{ > > + struct drm_device *dev = connector->dev; > > + struct drm_property *prop; > > + > > + prop = connector->active_bpc_property; > > + if (!prop) { > > + prop = drm_property_create_range(dev, 0, "active bpc", min, max); > > + if (!prop) > > + return -ENOMEM; > > + > > + connector->active_bpc_property = prop; > > + } > > + > > + drm_object_attach_property(&connector->base, prop, 0); > > + connector->state->active_bpc = 0; > > + > > + return 0; > > +} > > +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property); > > + > > /** > > * drm_connector_set_vrr_capable_property - sets the variable refresh rate > > * capable property for a connector > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h > > index 1922b278ffad..c58cba2b6afe 100644 > > --- a/include/drm/drm_connector.h > > +++ b/include/drm/drm_connector.h > > @@ -781,6 +781,13 @@ struct drm_connector_state { > > */ > > u8 max_bpc; > > > > + /** > > + * @active_bpc: Read only property set by the GPU driver to the actually > > + * applied bit depth of the pixels after evaluating all hardware > > + * limitations. > > + */ > > + u8 active_bpc; > > + > > /** > > * @hdr_output_metadata: > > * DRM blob property for HDR output metadata > > @@ -1380,6 +1387,12 @@ struct drm_connector { > > */ > > struct drm_property *max_bpc_property; > > > > + /** > > + * @active_bpc_property: Default connector property for the active bpc > > + * to be driven out of the connector. > > + */ > > + struct drm_property *active_bpc_property; > > + > > #define DRM_CONNECTOR_POLL_HPD (1 << 0) > > #define DRM_CONNECTOR_POLL_CONNECT (1 << 1) > > #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2) > > @@ -1698,6 +1711,8 @@ int drm_connector_set_panel_orientation_with_quirk( > > int width, int height); > > int drm_connector_attach_max_bpc_property(struct drm_connector *connector, > > int min, int max); > > +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, > > + int min, int max); > > > > /** > > * struct drm_tile_group - Tile group metadata >
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index 268bb69c2e2f..7ae4e40936b5 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -873,6 +873,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector, *val = 0; } else if (property == connector->max_bpc_property) { *val = state->max_requested_bpc; + } else if (property == connector->active_bpc_property) { + *val = state->active_bpc; } else if (connector->funcs->atomic_get_property) { return connector->funcs->atomic_get_property(connector, state, property, val); diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 7631f76e7f34..c0c3c09bfed0 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1195,6 +1195,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = { * drm_connector_attach_max_bpc_property() to create and attach the * property to the connector during initialization. * + * active bpc: + * This read-only range property tells userspace the pixel color bit depth + * actually used by the hardware display engine on "the cable" on a + * connector. The chosen value depends on hardware capabilities, both + * display engine and connected monitor, and the "max bpc" property. + * Drivers shall use drm_connector_attach_active_bpc_property() to install + * this property. + * * Connectors also have one standardized atomic property: * * CRTC_ID: @@ -2150,6 +2158,39 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector, } EXPORT_SYMBOL(drm_connector_attach_max_bpc_property); +/** + * drm_connector_attach_active_bpc_property - attach "active bpc" property + * @connector: connector to attach active bpc property on. + * @min: The minimum bit depth supported by the connector. + * @max: The maximum bit depth supported by the connector. + * + * This is used to check the applied bit depth on a connector. + * + * Returns: + * Zero on success, negative errno on failure. + */ +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, + int min, int max) +{ + struct drm_device *dev = connector->dev; + struct drm_property *prop; + + prop = connector->active_bpc_property; + if (!prop) { + prop = drm_property_create_range(dev, 0, "active bpc", min, max); + if (!prop) + return -ENOMEM; + + connector->active_bpc_property = prop; + } + + drm_object_attach_property(&connector->base, prop, 0); + connector->state->active_bpc = 0; + + return 0; +} +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property); + /** * drm_connector_set_vrr_capable_property - sets the variable refresh rate * capable property for a connector diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index 1922b278ffad..c58cba2b6afe 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -781,6 +781,13 @@ struct drm_connector_state { */ u8 max_bpc; + /** + * @active_bpc: Read only property set by the GPU driver to the actually + * applied bit depth of the pixels after evaluating all hardware + * limitations. + */ + u8 active_bpc; + /** * @hdr_output_metadata: * DRM blob property for HDR output metadata @@ -1380,6 +1387,12 @@ struct drm_connector { */ struct drm_property *max_bpc_property; + /** + * @active_bpc_property: Default connector property for the active bpc + * to be driven out of the connector. + */ + struct drm_property *active_bpc_property; + #define DRM_CONNECTOR_POLL_HPD (1 << 0) #define DRM_CONNECTOR_POLL_CONNECT (1 << 1) #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2) @@ -1698,6 +1711,8 @@ int drm_connector_set_panel_orientation_with_quirk( int width, int height); int drm_connector_attach_max_bpc_property(struct drm_connector *connector, int min, int max); +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, + int min, int max); /** * struct drm_tile_group - Tile group metadata
Add a new general drm property "active bpc" which can be used by graphic drivers to report the applied bit depth per pixel back to userspace. While "max bpc" can be used to change the color depth, there was no way to check which one actually got used. While in theory the driver chooses the best/highest color depth within the max bpc setting a user might not be fully aware what his hardware is or isn't capable off. This is meant as a quick way to double check the setup. In the future, automatic color calibration for screens might also depend on this information being available. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> --- drivers/gpu/drm/drm_atomic_uapi.c | 2 ++ drivers/gpu/drm/drm_connector.c | 41 +++++++++++++++++++++++++++++++ include/drm/drm_connector.h | 15 +++++++++++ 3 files changed, 58 insertions(+)