Re: [PATCH 3/7] drm/amd/display: Add handling for new "active color format" property

2024-01-11 Thread Werner Sembach

Hi,

Am 10.01.24 um 18:15 schrieb Andri Yngvason:

Hi Werner,

mið., 10. jan. 2024 kl. 13:14 skrifaði Werner Sembach 
:

Hi,

Am 10.01.24 um 14:09 schrieb Daniel Vetter:

On Wed, 10 Jan 2024 at 13:53, Andri Yngvason  wrote:

mið., 10. jan. 2024 kl. 11:10 skrifaði Daniel Vetter :

On Tue, Jan 09, 2024 at 06:11:00PM +, Andri Yngvason wrote:

+ /* Extract information from crtc to communicate it to userspace as 
connector properties */
+ for_each_new_connector_in_state(state, connector, new_con_state, i) {
+ struct drm_crtc *crtc = new_con_state->crtc;
+ struct dc_stream_state *stream;
+
+ if (crtc) {
+ new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
+ dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+ stream = dm_new_crtc_state->stream;
+
+ if (stream) {
+ 
drm_connector_set_active_color_format_property(connector,
+ 
convert_dc_pixel_encoding_into_drm_color_format(
+ 
dm_new_crtc_state->stream->timing.pixel_encoding));
+ }
+ } else {
+ drm_connector_set_active_color_format_property(connector, 
0);

Just realized an even bigger reason why your current design doesn't work:
You don't have locking here.

And you cannot grab the required lock, which is
drm_dev->mode_config.mutex, because that would result in deadlocks. So
this really needs to use the atomic state based design I've described.


Maybe we should just drop "actual color format" and instead fail the
modeset if the "preferred color format" property cannot be satisfied?
It seems like the simplest thing to do here, though it is perhaps less
convenient for userspace. In that case, the "preferred color format"
property should just be called "color format".

Yeah that's more in line with how other atomic properties work. This
way userspace can figure out what works with a TEST_ONLY commit too.
And for this to work you probably want to have an "automatic" setting
too.
-Sima

The problem with TEST_ONLY probing is that color format settings are
interdependent: https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_966634

So changing any other setting may require every color format to be TEST_ONLY
probed again.


If we put a bit map containing the possible color formats into
drm_mode_mode_info (I'm thinking that it could go into flags), we'd be
able to eliminate a bunch of combinations early on. Do you think that
would make things more bearable?


That would eliminate some, but note that for example YCBCR444 needs a faster 
pixel clock then YCBCR420, so it's interdependent with everything else that 
changes the required pixel clock like bpc, resolution and refresh rate.


So the config space is n-dimensional with no "right angle box" clearly 
separating working from non working combinations.


But I just had the idea:

Currently in KDE and Gnome UI you first select the resolution, to then wee what 
refresh rates are available. So I guess this concept could be appended to color 
properties -> Define a sequence for the different properties to be applied 
across all drivers and as soon as you select one, the next property in the 
sequence is TEST_ONLYed.


e.g.:

1. Select resolution -> Available refresh rates are updated

2. Select refresh rate -> Available color formats are updated

3. Select color format -> Available bpc are updated

etc.

So you can't select a bpc that doesn't fit your current color format. Changing 
color format can change the available bpc. One maybe counter intuitive thing 
here is that color format "auto" might not have all bpc settings available, as 
auto will for example actually be RGB which has higher pixel clock requirements 
then ycbcr420. And in this model, color format is always decided first. Or vice 
versa if bpc is decided to be before color format in the sequence.




I'm thinking, something like this:
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 128d09138ceb3..59980803cb89e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -124,6 +124,13 @@ extern "C" {
  #define  DRM_MODE_FLAG_PIC_AR_256_135 \
 (DRM_MODE_PICTURE_ASPECT_256_135<<19)

+/* Possible color formats (4 bits) */
+#define DRM_MODE_FLAG_COLOR_FORMAT_MASK (0x0f << 22)
+#define DRM_MODE_FLAG_COLOR_FORMAT_RGB (1 << 22)
+#define DRM_MODE_FLAG_COLOR_FORMAT_YCBCR444 (1 << 23)
+#define DRM_MODE_FLAG_COLOR_FORMAT_YCBCR422 (1 << 24)
+#define DRM_MODE_FLAG_COLOR_FORMAT_YCBCR420 (1 << 25)
+
  #define  DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
  DRM_MODE_FLAG_NHSYNC | \
  

Re: [PATCH 5/7] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2024-01-10 Thread Werner Sembach

Hi,

Am 10.01.24 um 14:42 schrieb Andri Yngvason:

mið., 10. jan. 2024 kl. 13:09 skrifaði Werner Sembach:

Hi,

Am 10.01.24 um 11:11 schrieb Andri Yngvason:

Hi,

mið., 10. jan. 2024 kl. 09:27 skrifaði Maxime Ripard:

On Tue, Jan 09, 2024 at 06:11:02PM +, Andri Yngvason wrote:

From: Werner Sembach

Add a new general drm property "preferred color format" which can be used
by userspace to tell the graphic drivers to which color format to use.

Possible options are:
  - auto (default/current behaviour)
  - rgb
  - ycbcr444
  - ycbcr422 (not supported by both amdgpu and i915)
  - ycbcr420

In theory the auto option should choose the best available option for the
current setup, but because of bad internal conversion some monitors look
better with rgb and some with ycbcr444.

I looked at the patch and I couldn't find what is supposed to happen if
you set it to something else than auto, and the driver can't match that.
Are we supposed to fallback to the "auto" behaviour, or are we suppose
to reject the mode entirely?

The combination with the active output format property suggests the
former, but we should document it explicitly.

It is also my understanding that it should fall back to the "auto"
behaviour. I will add this to the documentation.

Yes, that was the intention, and then userspace can check, but it wasn't well
received:https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_964530

Actually a lot of the thoughts that went into the original patch set can be
found in that topic.

There was another iteration of the patch set that I never finished and sent to
the LKML because I got discouraged by this:
https://lore.kernel.org/dri-devel/20210623102923.70877c1a@eldfell/

Well, I've implemented this for sway and wlroots now and Simon has
reacted positively, so this does appear likely to end up as a feature
in wlroots based compositors.


I can try to dig it up, but it is completely untested and I don't think I still
have the respective TODO list anymore, so I don't know if it is a better or
worst starting point than the last iteration I sent to the LKML.


You can send the patches to me if you want and I can see if they're
useful. I'm really only interested in the color format part though.
Alternatively, you can continue your work and post it to LKML and I
can focus on the userspace side and testing. By the way, I have an
HDMI analyzer that can tell me the actual color format.


Searched for what I still had in my private repo, see attachments, filename is 
the branch name I used and like I said: I don't know which state these branches 
are in.


The hacking_ branch was based on 25fe90f43fa312213b653dc1f12fd2d80f855883 from 
linux-next and the rejected_ one on 132b189b72a94328f17fd70321bfe63e5b4208e9 
from drm-tip.


And the rejected_ one is 2 weeks newer.

To pick it up again I would first need to allocate some time for it, ... which 
could take some time.


With a HDMI analyzer at hand you are better equipped then me already. I was 
working with printf statements, Monitor OSD's and test patterns like 
https://media.extron.com/public/technology/landing/vector4k/img/scalfe-444Chroma.png 
and http://www.lagom.nl/lcd-test/ while being red blind xD.




Thanks,
Andri

hacking_drm_color_management_no_immutable_flag.tar.gz
Description: application/gzip


rejected_drm_color_management.tar.gz
Description: application/gzip


Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

2024-01-10 Thread Werner Sembach

Hi,

Am 09.01.24 um 19:10 schrieb Andri Yngvason:

From: Werner Sembach 

Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.

There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor, the GPU, and the connection used and what the default
behaviour of the used driver is (e.g. amdgpu prefers YCbCr 4:4:4 while i915
prefers RGB). This property helps eliminating the guessing on this point.

In the future, automatic color calibration for screens might also depend on
this information being available.

Signed-off-by: Werner Sembach 
Signed-off-by: Andri Yngvason 
Tested-by: Andri Yngvason 


One suggestion from back then was, instead picking out singular properties like 
"active color format", to just expose whatever the last HDMI or DP metadata 
block(s)/frame(s) that was sent over the display wire was to userspace and 
accompanying it with a parsing script.


Question: Does the driver really actually know what the GPU is ultimatively 
sending out the wire, or is that decided by a final firmware blob we have no 
info about?


Greetings

Werner


---
  drivers/gpu/drm/drm_connector.c | 63 +
  include/drm/drm_connector.h | 10 ++
  2 files changed, 73 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index c3725086f4132..30d62e505d188 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1061,6 +1061,14 @@ static const struct drm_prop_enum_list 
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native,  "Native"}, /* DP */
  };
  
+static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {

+   { 0, "not applicable" },
+   { DRM_COLOR_FORMAT_RGB444, "rgb" },
+   { DRM_COLOR_FORMAT_YCBCR444, "ycbcr444" },
+   { DRM_COLOR_FORMAT_YCBCR422, "ycbcr422" },
+   { DRM_COLOR_FORMAT_YCBCR420, "ycbcr420" },
+};
+
  DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 drm_dp_subconnector_enum_list)
  
@@ -1390,6 +1398,15 @@ static const u32 dp_colorspaces =

   *drm_connector_attach_max_bpc_property() to create and attach the
   *property to the connector during initialization.
   *
+ * active color format:
+ * This read-only property tells userspace the color format 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. Drivers shall use
+ * drm_connector_attach_active_color_format_property() to install this
+ * property. Possible values are "not applicable", "rgb", "ycbcr444",
+ * "ycbcr422", and "ycbcr420".
+ *
   * Connectors also have one standardized atomic property:
   *
   * CRTC_ID:
@@ -2451,6 +2468,52 @@ int drm_connector_attach_max_bpc_property(struct 
drm_connector *connector,
  }
  EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
  
+/**

+ * drm_connector_attach_active_color_format_property - attach "active color 
format" property
+ * @connector: connector to attach active color format property on.
+ *
+ * This is used to check the applied color format on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_format_property(struct drm_connector 
*connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   if (!connector->active_color_format_property) {
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, 
"active color format",
+   
drm_active_color_format_enum_list,
+   
ARRAY_SIZE(drm_active_color_format_enum_list));
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_color_format_property = prop;
+   }
+
+   drm_object_attach_property(>base, prop, 0);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_format_property);
+
+/**
+ * drm_connector_set_active_color_format_property - sets the active color 
format property for a
+ * connector
+ * @connector: drm connector
+ * @active_color_format: color format for the connector currently active "on the 
cable"
+ *
+ * Should be used by atomic drivers to update the active color format over a 
connector.
+ */
+void drm_connector_set_active_color_format_property(struct drm_connector 
*connector,
+   u32 active_color_format)
+{
+   drm_object_property_s

Re: [PATCH 5/7] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2024-01-10 Thread Werner Sembach

Hi,

Am 10.01.24 um 11:11 schrieb Andri Yngvason:

Hi,

mið., 10. jan. 2024 kl. 09:27 skrifaði Maxime Ripard :

On Tue, Jan 09, 2024 at 06:11:02PM +, Andri Yngvason wrote:

From: Werner Sembach 

Add a new general drm property "preferred color format" which can be used
by userspace to tell the graphic drivers to which color format to use.

Possible options are:
 - auto (default/current behaviour)
 - rgb
 - ycbcr444
 - ycbcr422 (not supported by both amdgpu and i915)
 - ycbcr420

In theory the auto option should choose the best available option for the
current setup, but because of bad internal conversion some monitors look
better with rgb and some with ycbcr444.

I looked at the patch and I couldn't find what is supposed to happen if
you set it to something else than auto, and the driver can't match that.
Are we supposed to fallback to the "auto" behaviour, or are we suppose
to reject the mode entirely?

The combination with the active output format property suggests the
former, but we should document it explicitly.

It is also my understanding that it should fall back to the "auto"
behaviour. I will add this to the documentation.


Yes, that was the intention, and then userspace can check, but it wasn't well 
received: https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_964530


Actually a lot of the thoughts that went into the original patch set can be 
found in that topic.


There was another iteration of the patch set that I never finished and sent to 
the LKML because I got discouraged by this: 
https://lore.kernel.org/dri-devel/20210623102923.70877c1a@eldfell/


I can try to dig it up, but it is completely untested and I don't think I still 
have the respective TODO list anymore, so I don't know if it is a better or 
worst starting point than the last iteration I sent to the LKML.


Greetings

Werner



Thanks,
Andri


Re: [PATCH 3/7] drm/amd/display: Add handling for new "active color format" property

2024-01-10 Thread Werner Sembach

Hi,

Am 10.01.24 um 14:09 schrieb Daniel Vetter:

On Wed, 10 Jan 2024 at 13:53, Andri Yngvason  wrote:

mið., 10. jan. 2024 kl. 11:10 skrifaði Daniel Vetter :

On Tue, Jan 09, 2024 at 06:11:00PM +, Andri Yngvason wrote:

+ /* Extract information from crtc to communicate it to userspace as 
connector properties */
+ for_each_new_connector_in_state(state, connector, new_con_state, i) {
+ struct drm_crtc *crtc = new_con_state->crtc;
+ struct dc_stream_state *stream;
+
+ if (crtc) {
+ new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
+ dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+ stream = dm_new_crtc_state->stream;
+
+ if (stream) {
+ 
drm_connector_set_active_color_format_property(connector,
+ 
convert_dc_pixel_encoding_into_drm_color_format(
+ 
dm_new_crtc_state->stream->timing.pixel_encoding));
+ }
+ } else {
+ drm_connector_set_active_color_format_property(connector, 
0);

Just realized an even bigger reason why your current design doesn't work:
You don't have locking here.

And you cannot grab the required lock, which is
drm_dev->mode_config.mutex, because that would result in deadlocks. So
this really needs to use the atomic state based design I've described.


Maybe we should just drop "actual color format" and instead fail the
modeset if the "preferred color format" property cannot be satisfied?
It seems like the simplest thing to do here, though it is perhaps less
convenient for userspace. In that case, the "preferred color format"
property should just be called "color format".

Yeah that's more in line with how other atomic properties work. This
way userspace can figure out what works with a TEST_ONLY commit too.
And for this to work you probably want to have an "automatic" setting
too.
-Sima


The problem with TEST_ONLY probing is that color format settings are 
interdependent: https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_966634


So changing any other setting may require every color format to be TEST_ONLY 
probed again.


Greetings

Werner



Re: [Intel-gfx] [PATCH] drm/i915/psr: Use calculated io and fast wake lines

2023-02-24 Thread Werner Sembach



Am 21.02.23 um 09:53 schrieb Jouni Högander:

Currently we are using hardcoded 7 for io and fast wake lines.

According to Bspec io and fast wake times are both 42us for
DISPLAY_VER >= 12 and 50us and 32us for older platforms.

Calculate line counts for these and configure them into PSR2_CTL
accordingly

Use 45 us for the fast wake calculation as 42 seems to be too
tight based on testing.

Bspec: 49274, 4289


Thanks for fixing this.

Tested-by: Werner Sembach 



Cc: Mika Kahola 
Cc: José Roberto de Souza 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7725
Signed-off-by: Jouni Högander 
---
  .../drm/i915/display/intel_display_types.h|  2 +
  drivers/gpu/drm/i915/display/intel_psr.c  | 78 +++
  2 files changed, 63 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9ccae7a46020..fc15f4e5d49f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1634,6 +1634,8 @@ struct intel_psr {
bool psr2_sel_fetch_cff_enabled;
bool req_psr2_sdp_prior_scanline;
u8 sink_sync_latency;
+   u8 io_wake_lines;
+   u8 fast_wake_lines;
ktime_t last_entry_attempt;
ktime_t last_exit;
bool sink_not_reliable;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 2954759e9d12..059e220144ce 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -542,6 +542,14 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
val |= EDP_PSR2_FRAME_BEFORE_SU(max_t(u8, 
intel_dp->psr.sink_sync_latency + 1, 2));
val |= intel_psr2_get_tp_time(intel_dp);
  
+	if (DISPLAY_VER(dev_priv) >= 12) {

+   if (intel_dp->psr.io_wake_lines < 9 &&
+   intel_dp->psr.fast_wake_lines < 9)
+   val |= TGL_EDP_PSR2_BLOCK_COUNT_NUM_2;
+   else
+   val |= TGL_EDP_PSR2_BLOCK_COUNT_NUM_3;
+   }
+
/* Wa_22012278275:adl-p */
if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_E0)) {
static const u8 map[] = {
@@ -558,31 +566,21 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
 * Still using the default IO_BUFFER_WAKE and FAST_WAKE, see
 * comments bellow for more information
 */
-   u32 tmp, lines = 7;
-
-   val |= TGL_EDP_PSR2_BLOCK_COUNT_NUM_2;
+   u32 tmp;
  
-		tmp = map[lines - TGL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES];

+   tmp = map[intel_dp->psr.io_wake_lines - 
TGL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES];
tmp = tmp << TGL_EDP_PSR2_IO_BUFFER_WAKE_SHIFT;
val |= tmp;
  
-		tmp = map[lines - TGL_EDP_PSR2_FAST_WAKE_MIN_LINES];

+   tmp = map[intel_dp->psr.fast_wake_lines - 
TGL_EDP_PSR2_FAST_WAKE_MIN_LINES];
tmp = tmp << TGL_EDP_PSR2_FAST_WAKE_MIN_SHIFT;
val |= tmp;
} else if (DISPLAY_VER(dev_priv) >= 12) {
-   /*
-* TODO: 7 lines of IO_BUFFER_WAKE and FAST_WAKE are default
-* values from BSpec. In order to setting an optimal power
-* consumption, lower than 4k resolution mode needs to decrease
-* IO_BUFFER_WAKE and FAST_WAKE. And higher than 4K resolution
-* mode needs to increase IO_BUFFER_WAKE and FAST_WAKE.
-*/
-   val |= TGL_EDP_PSR2_BLOCK_COUNT_NUM_2;
-   val |= TGL_EDP_PSR2_IO_BUFFER_WAKE(7);
-   val |= TGL_EDP_PSR2_FAST_WAKE(7);
+   val |= TGL_EDP_PSR2_IO_BUFFER_WAKE(intel_dp->psr.io_wake_lines);
+   val |= TGL_EDP_PSR2_FAST_WAKE(intel_dp->psr.fast_wake_lines);
} else if (DISPLAY_VER(dev_priv) >= 9) {
-   val |= EDP_PSR2_IO_BUFFER_WAKE(7);
-   val |= EDP_PSR2_FAST_WAKE(7);
+   val |= EDP_PSR2_IO_BUFFER_WAKE(intel_dp->psr.io_wake_lines);
+   val |= EDP_PSR2_FAST_WAKE(intel_dp->psr.fast_wake_lines);
}
  
  	if (intel_dp->psr.req_psr2_sdp_prior_scanline)

@@ -829,6 +827,46 @@ static bool 
_compute_psr2_sdp_prior_scanline_indication(struct intel_dp *intel_d
return true;
  }
  
+static bool _compute_psr2_wake_times(struct intel_dp *intel_dp,

+struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   int io_wake_lines, io_wake_time, fast_wake_lines, fast_wake_time;
+   u8 max_wake_lines;
+
+   if (DISPLAY_VER(i915) >= 12) {
+   io_wake_time = 42;
+   /*
+* According to Bspec it's 42us, but based on testing
+* it is not enoug

Re: [Intel-gfx] [PATCH 0/2] Add quirk to disable PSR 2 on Tongfang PHxTxX1 and PHxTQx1

2023-02-23 Thread Werner Sembach



Am 23.02.23 um 19:56 schrieb Werner Sembach:


Am 23.02.23 um 19:26 schrieb Hogander, Jouni:

On Wed, 2023-02-22 at 15:17 +0100, Werner Sembach wrote:

On these Barebones PSR 2 is recognized as supported but is very
buggy:
- Upper third of screen does sometimes not updated, resulting in
disappearing cursors or ghosts of already closed Windows saying
behind.
- Approximately 40 px from the bottom edge a 3 pixel wide strip of
randomly
colored pixels is flickering.

PSR 1 is working fine however.

This patchset introduces a new quirk to disable PSR 2 specifically on
known
buggy devices and applies it to the Tongfang PHxTxX1 and PHxTQx1
barebones.

I've been thinking something similar as there is still at least one
issue which seems to be like panel side issue:

https://gitlab.freedesktop.org/drm/intel/-/issues/7836

Did you considered dpcd_quirk_list in drivers/gpu/drm/drm_dp_helper.c?

I'm not sure which one is more correct though...
Imho, since the proper fix lies within the Intel driver the quirk should also 
lie within the Intel driver, because even if the panel has the same problem 
combined with an AMD or NVIDIA card the proper fix for them will most likely 
be land in the same kernel version. So there could be a period where you no 
longer want the quirk for devices combining the panel with an Intel gpu but 
still with an AMD GPU or vice versa.

*the proper fix for them will most likely not be in the same kernel version.



Signed-off-by: Werner Sembach 
Cc: 




Re: [Intel-gfx] [PATCH 0/2] Add quirk to disable PSR 2 on Tongfang PHxTxX1 and PHxTQx1

2023-02-23 Thread Werner Sembach



Am 23.02.23 um 19:26 schrieb Hogander, Jouni:

On Wed, 2023-02-22 at 15:17 +0100, Werner Sembach wrote:

On these Barebones PSR 2 is recognized as supported but is very
buggy:
- Upper third of screen does sometimes not updated, resulting in
disappearing cursors or ghosts of already closed Windows saying
behind.
- Approximately 40 px from the bottom edge a 3 pixel wide strip of
randomly
colored pixels is flickering.

PSR 1 is working fine however.

This patchset introduces a new quirk to disable PSR 2 specifically on
known
buggy devices and applies it to the Tongfang PHxTxX1 and PHxTQx1
barebones.

I've been thinking something similar as there is still at least one
issue which seems to be like panel side issue:

https://gitlab.freedesktop.org/drm/intel/-/issues/7836

Did you considered dpcd_quirk_list in drivers/gpu/drm/drm_dp_helper.c?

I'm not sure which one is more correct though...
Imho, since the proper fix lies within the Intel driver the quirk should also 
lie within the Intel driver, because even if the panel has the same problem 
combined with an AMD or NVIDIA card the proper fix for them will most likely be 
land in the same kernel version. So there could be a period where you no longer 
want the quirk for devices combining the panel with an Intel gpu but still with 
an AMD GPU or vice versa.



Signed-off-by: Werner Sembach 
Cc: 




Re: [Intel-gfx] [PATCH 2/2] Apply quirk to disable PSR 2 on Tongfang PHxTxX1 and PHxTQx1

2023-02-23 Thread Werner Sembach



Am 23.02.23 um 07:27 schrieb Hogander, Jouni:

On Wed, 2023-02-22 at 15:13 -0500, Rodrigo Vivi wrote:

On Wed, Feb 22, 2023 at 03:17:55PM +0100, Werner Sembach wrote:

On these Barebones PSR 2 is recognized as supported but is very
buggy:
- Upper third of screen does sometimes not updated, resulting in
disappearing cursors or ghosts of already closed Windows saying
behind.
- Approximately 40 px from the bottom edge a 3 pixel wide strip of
randomly
colored pixels is flickering.

PSR 1 is working fine however.

I wonder if this is really about the panel's PSR2 or about the
userspace
there not marking the dirtyfb? I know I know... it is not userspace
fault...

But I wonder if the case you got here highlights the fact that we
have
a substantial bug in the i915 itself in regards to PSR2 API.

Jose, Jouni, ideas on how to check what could be happening here?

There is already fix for this (Thanks to Werner Sembach for testing the
patch):

https://patchwork.freedesktop.org/series/114217/


Yes, thanks for creating that patch ^^

I posted this quirk patch just as an possible alternative for stable if that 
other patch is considered not suitable for it (lets wait and see).


And to get some feedback if something like this could be a viable workaround if 
similar bugs appear in the future.





oh, btw, Werner, do we have an  open gilab issue for this?

https://gitlab.freedesktop.org/drm/intel/-/issues/7347


Thanks,
Rodrigo.


Signed-off-by: Werner Sembach 
Cc: 
---
  drivers/gpu/drm/i915/display/intel_quirks.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
b/drivers/gpu/drm/i915/display/intel_quirks.c
index ce6d0fe6448f5..eeb32d3189f5c 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -65,6 +65,10 @@ static void
quirk_no_pps_backlight_power_hook(struct drm_i915_private *i915)
 drm_info(>drm, "Applying no pps backlight power
quirk\n");
  }
  
+/*

+ * Tongfang PHxTxX1 and PHxTQx1 devices have support for PSR 2 but
it is broken
+ * on Linux. PSR 1 however works just fine.
+ */
  static void quirk_no_psr2(struct drm_i915_private *i915)
  {
 intel_set_quirk(i915, QUIRK_NO_PSR2);
@@ -205,6 +209,10 @@ static struct intel_quirk intel_quirks[] = {
 /* ECS Liva Q2 */
 { 0x3185, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time
},
 { 0x3184, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time
},
+
+   /* Tongfang PHxTxX1 and PHxTQx1/TUXEDO InfinityBook 14 Gen6
*/
+   { 0x9a49, 0x1d05, 0x1105, quirk_no_psr2 },
+   { 0x9a49, 0x1d05, 0x114c, quirk_no_psr2 },
  };
  
  void intel_init_quirks(struct drm_i915_private *i915)

--
2.34.1



Re: [Intel-gfx] [PATCH 0/2] Add quirk to disable PSR 2 on Tongfang PHxTxX1 and PHxTQx1

2023-02-22 Thread Werner Sembach



Am 22.02.23 um 15:17 schrieb Werner Sembach:

On these Barebones PSR 2 is recognized as supported but is very buggy:
- Upper third of screen does sometimes not updated, resulting in
disappearing cursors or ghosts of already closed Windows saying behind.
- Approximately 40 px from the bottom edge a 3 pixel wide strip of randomly
colored pixels is flickering.

PSR 1 is working fine however.

This patchset introduces a new quirk to disable PSR 2 specifically on known
buggy devices and applies it to the Tongfang PHxTxX1 and PHxTQx1 barebones.

Signed-off-by: Werner Sembach 
Cc: 


Parralel to this there is a patch fixing the root cause of this issue: 
https://gitlab.freedesktop.org/drm/intel/-/issues/7347#note_1785094


So this quirk might only be relevant for stable kernels, depending on when that 
other patch gets merged.




[Intel-gfx] [PATCH 0/2] Add quirk to disable PSR 2 on Tongfang PHxTxX1 and PHxTQx1

2023-02-22 Thread Werner Sembach
On these Barebones PSR 2 is recognized as supported but is very buggy:
- Upper third of screen does sometimes not updated, resulting in
disappearing cursors or ghosts of already closed Windows saying behind.
- Approximately 40 px from the bottom edge a 3 pixel wide strip of randomly
colored pixels is flickering.

PSR 1 is working fine however.

This patchset introduces a new quirk to disable PSR 2 specifically on known
buggy devices and applies it to the Tongfang PHxTxX1 and PHxTQx1 barebones.

Signed-off-by: Werner Sembach 
Cc: 




[Intel-gfx] [PATCH 2/2] Apply quirk to disable PSR 2 on Tongfang PHxTxX1 and PHxTQx1

2023-02-22 Thread Werner Sembach
On these Barebones PSR 2 is recognized as supported but is very buggy:
- Upper third of screen does sometimes not updated, resulting in
disappearing cursors or ghosts of already closed Windows saying behind.
- Approximately 40 px from the bottom edge a 3 pixel wide strip of randomly
colored pixels is flickering.

PSR 1 is working fine however.

Signed-off-by: Werner Sembach 
Cc: 
---
 drivers/gpu/drm/i915/display/intel_quirks.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
b/drivers/gpu/drm/i915/display/intel_quirks.c
index ce6d0fe6448f5..eeb32d3189f5c 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -65,6 +65,10 @@ static void quirk_no_pps_backlight_power_hook(struct 
drm_i915_private *i915)
drm_info(>drm, "Applying no pps backlight power quirk\n");
 }
 
+/*
+ * Tongfang PHxTxX1 and PHxTQx1 devices have support for PSR 2 but it is broken
+ * on Linux. PSR 1 however works just fine.
+ */
 static void quirk_no_psr2(struct drm_i915_private *i915)
 {
intel_set_quirk(i915, QUIRK_NO_PSR2);
@@ -205,6 +209,10 @@ static struct intel_quirk intel_quirks[] = {
/* ECS Liva Q2 */
{ 0x3185, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time },
{ 0x3184, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time },
+
+   /* Tongfang PHxTxX1 and PHxTQx1/TUXEDO InfinityBook 14 Gen6 */
+   { 0x9a49, 0x1d05, 0x1105, quirk_no_psr2 },
+   { 0x9a49, 0x1d05, 0x114c, quirk_no_psr2 },
 };
 
 void intel_init_quirks(struct drm_i915_private *i915)
-- 
2.34.1



[Intel-gfx] [PATCH 1/2] Add quirk to disable PSR 2 on a per device basis

2023-02-22 Thread Werner Sembach
This adds the possibility to disable PSR 2 explicitly using the intel
quirk table for devices where PSR 2 is borked, but PSR 1 works fine.

Signed-off-by: Werner Sembach 
Cc: 
---
 drivers/gpu/drm/i915/display/intel_psr.c| 4 +++-
 drivers/gpu/drm/i915/display/intel_quirks.c | 6 ++
 drivers/gpu/drm/i915/display/intel_quirks.h | 1 +
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 5b678916e6db5..4607f3c4cf592 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -37,6 +37,7 @@
 #include "intel_psr.h"
 #include "intel_snps_phy.h"
 #include "skl_universal_plane.h"
+#include "intel_quirks.h"
 
 /**
  * DOC: Panel Self Refresh (PSR/SRD)
@@ -851,7 +852,8 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
int psr_max_h = 0, psr_max_v = 0, max_bpp = 0;
 
-   if (!intel_dp->psr.sink_psr2_support)
+   if (!intel_dp->psr.sink_psr2_support ||
+   intel_has_quirk(dev_priv, QUIRK_NO_PSR2))
return false;
 
/* JSL and EHL only supports eDP 1.3 */
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 6e48d3bcdfec5..ce6d0fe6448f5 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -65,6 +65,12 @@ static void quirk_no_pps_backlight_power_hook(struct 
drm_i915_private *i915)
drm_info(>drm, "Applying no pps backlight power quirk\n");
 }
 
+static void quirk_no_psr2(struct drm_i915_private *i915)
+{
+   intel_set_quirk(i915, QUIRK_NO_PSR2);
+   drm_info(>drm, "Applying No PSR 2 quirk\n");
+}
+
 struct intel_quirk {
int device;
int subsystem_vendor;
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.h 
b/drivers/gpu/drm/i915/display/intel_quirks.h
index 10a4d163149fd..2e0b788a44a1e 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.h
+++ b/drivers/gpu/drm/i915/display/intel_quirks.h
@@ -17,6 +17,7 @@ enum intel_quirk_id {
QUIRK_INVERT_BRIGHTNESS,
QUIRK_LVDS_SSC_DISABLE,
QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK,
+   QUIRK_NO_PSR2,
 };
 
 void intel_init_quirks(struct drm_i915_private *i915);
-- 
2.34.1



Re: [Intel-gfx] [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks

2022-07-13 Thread Werner Sembach

Hi,

On 7/12/22 21:39, Hans de Goede wrote:

acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.

After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.

So this is no longer an issue an the quirks are no longer needed.

Cc: Werner Sembach 
Signed-off-by: Hans de Goede 


Tested and can confirm: The quirks are no longer needed with this Patchset.

Tested-by: Werner Sembach 

Kind Regards,

Werner Sembach


---
  drivers/acpi/video_detect.c | 75 -
  1 file changed, 75 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 2a4d376a703e..4b9395d1bda7 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -599,81 +599,6 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_BOARD_NAME, "N250P"),
},
},
-   /*
-* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
-* working native and video interface. However the default detection
-* mechanism first registers the video interface before unregistering
-* it again and switching to the native interface during boot. This
-* results in a dangling SBIOS request for backlight change for some
-* reason, causing the backlight to switch to ~2% once per boot on the
-* first power cord connect or disconnect event. Setting the native
-* interface explicitly circumvents this buggy behaviour, by avoiding
-* the unregistering process.
-*/
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "AURA1501"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "EDUBOOK1502"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xNU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xNU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xNU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
-   },
-   },
  
  	/*

 * Desktops which falsely report a backlight and which our heuristics


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

2021-08-03 Thread Werner Sembach
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: [Intel-gfx] [PATCH v5 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property

2021-07-14 Thread Werner Sembach

Am 30.06.21 um 17:10 schrieb Werner Sembach:

This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.

Signed-off-by: Werner Sembach 
---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 14 +++---
  .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  4 
  2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 02a5809d4993..80d5a11fb0c5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5247,7 +5247,8 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
  }
  
  static enum dc_color_space

-get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
+get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
+  enum drm_mode_color_range preferred_color_range)
  {
enum dc_color_space color_space = COLOR_SPACE_SRGB;
  
@@ -5278,7 +5279,10 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)

}
break;
case PIXEL_ENCODING_RGB:
-   color_space = COLOR_SPACE_SRGB;
+   if (preferred_color_range == 
DRM_MODE_COLOR_RANGE_LIMITED_16_235)
+   color_space = COLOR_SPACE_SRGB_LIMITED;
+   else
+   color_space = COLOR_SPACE_SRGB;
break;


After some testing I found out, that what I did here, was useless.

amdgpu actually never sets the quantization_range range in the 
hdmi_avi_infoframe and from that I guess any quantization range, besides 
the default one, is not implemented in multiple places


Until limited RGB is properly implemented in amdgpu there kind of is no 
purpose of generalizing the Broadcast RGB switch.


  
  	default:

@@ -5424,7 +5428,10 @@ static void fill_stream_properties_from_drm_display_mode(
  
  	timing_out->aspect_ratio = get_aspect_ratio(mode_in);
  
-	stream->output_color_space = get_output_color_space(timing_out);

+   stream->output_color_space = get_output_color_space(timing_out,
+   connector_state ?
+   
connector_state->preferred_color_range :
+   
DRM_MODE_COLOR_RANGE_UNSET);
  
  	stream->out_transfer_func->type = TF_TYPE_PREDEFINED;

stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
@@ -7775,6 +7782,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
drm_connector_attach_active_bpc_property(>base, 8, 
16);

drm_connector_attach_preferred_color_format_property(>base);

drm_connector_attach_active_color_format_property(>base);
+   
drm_connector_attach_preferred_color_range_property(>base);

drm_connector_attach_active_color_range_property(>base);
}
  
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c

index 2563788ba95a..80e1389fd0ec 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -421,6 +421,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_color_format_property)

drm_connector_attach_active_color_format_property(>base);
  
+	connector->preferred_color_range_property = master->base.preferred_color_range_property;

+   if (connector->preferred_color_range_property)
+   
drm_connector_attach_preferred_color_range_property(>base);
+
connector->active_color_range_property = 
master->base.active_color_range_property;
if (connector->active_color_range_property)

drm_connector_attach_active_color_range_property(>base);

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


Re: [Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-07-14 Thread Werner Sembach

Am 01.07.21 um 13:30 schrieb Werner Sembach:

Am 01.07.21 um 09:42 schrieb Pekka Paalanen:

On Wed, 30 Jun 2021 11:42:10 +0200
Werner Sembach  wrote:


Am 30.06.21 um 10:21 schrieb Pekka Paalanen:

On Tue, 29 Jun 2021 13:02:05 +0200
Werner Sembach  wrote:
  

Am 28.06.21 um 19:03 schrieb Werner Sembach:

Am 18.06.21 um 11:11 schrieb Werner Sembach:

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 
---
   drivers/gpu/drm/drm_connector.c | 51 +
   include/drm/drm_connector.h |  8 ++
   2 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..943f6b61053b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1197,6 +1197,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.
+ *

Regarding "on the cable" and dithering: As far as I can tell, what the 
dithering option does, is setting a hardware
register here:

- 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534

- 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571

So dithering seems to be calculated by fixed purpose hardware/firmware outside 
of the driver?

The Intel driver does not seem to set a target bpc/bpp for this hardware so I 
guess it defaults to 6 or 8 bpc?

Never mind it does. This switch-case does affect the dithering output:
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537

Hi,

I obviously do not know the intel driver or hardware at all, but
to me that just looks like translating from bits per pixel to bits per
channel in RGB mapping?

No, if i understand the documentation correctly: Writing bit depth here
with dithering enabled sets the dithering target bpc.
  

As found in this documentation p.548:
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf

So max bpc and active bpc are affecting/affected by the bpc after dithering.

By definition, if the cable carries N bpc, then dithering does not
change that. The cable still carries N bpc, but due to spatial or
temporal dithering, the *observed* color resolution may or may not be
higher than the cable bpc.

Yes, and max bpc and active bpc tell the cable bpc ist not the
*observed* bpc.

Of course, if the cable bpc is 8, and dithering targets 6 bpc, then 2
LSB on the cable are always zero, right?

I would assume that in this case only 6 bpc are actually send? Isn't the
whole thing of dithering that you can't send, for example, 8 bpc?

Maybe one would want to do that if the monitor has a 6 bit panel and it
simply ignored the 2 LSB, and the cable cannot go down to 6 bpc.

Is there dithering actually doing this? aka is my assumption above wrong?

AMD code that confused me before, is hinting that you might be right:
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L826

there is a set_clamp depth and a separate DCP_SPATIAL_DITHER_DEPTH_30BPP


So, what does "max bpc" mean right now?

It seems like dither on/off is insufficient information, one would also
need to control the dithering target bpc. I suppose the driver has a
policy on how it chooses the target bpc, but what is that policy? Is
the dither target bpc the cable bpc or the sink bpc?

Needless to say, I'm quite confused.

... We need someone who knows what dithering on intel and amd gpu
actually means.

But I don't want this to become a blocker for this patchset, because if
there is no dithering, which seems to be the norm, the active bpc
property is already really usefull as it is. So add a note to the docs
that the value might be invalid when dithering is active f

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-07-14 Thread Werner Sembach

Am 06.07.21 um 09:09 schrieb Pekka Paalanen:

On Mon, 5 Jul 2021 17:49:42 +0200
Werner Sembach  wrote:


Am 01.07.21 um 15:24 schrieb Pekka Paalanen:

On Thu, 1 Jul 2021 14:50:13 +0200
Werner Sembach  wrote:
  

Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
  

On Wed, 30 Jun 2021 11:20:18 +0200
Werner Sembach  wrote:


Am 30.06.21 um 10:41 schrieb Pekka Paalanen:


On Tue, 29 Jun 2021 13:39:18 +0200
Werner Sembach  wrote:
  

Am 29.06.21 um 13:17 schrieb Pekka Paalanen:

On Tue, 29 Jun 2021 08:12:54 +
Simon Ser  wrote:
 

On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen  
wrote:
 

yes, I think this makes sense, even if it is a property that one can't
tell for sure what it does before hand.

Using a pair of properties, preference and active, to ask for something
and then check what actually worked is good for reducing the
combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
test different KMS configurations. Userspace has a better chance of
finding a configuration that is possible.

OTOH, this has the problem than in UI one cannot tell the user in
advance which options are truly possible. Given that KMS properties are
rarely completely independent, and in this case known to depend on
several other KMS properties, I think it is good enough to know after
the fact.

If a driver does not use what userspace prefers, there is no way to
understand why, or what else to change to make it happen. That problem
exists anyway, because TEST_ONLY commits do not give useful feedback
but only a yes/no.

By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
property at a time), user-space can discover which property makes the atomic
commit fail.

That works if the properties are independent of each other. Color
range, color format, bpc and more may all be interconnected,
allowing only certain combinations to work.

If all these properties have "auto" setting too, then it would be
possible to probe each property individually, but that still does not
tell which combinations are valid.

If you probe towards a certain configuration by setting the properties
one by one, then depending on the order you pick the properties, you
may come to a different conclusion on which property breaks the
configuration.

My mind crossed another point that must be considered: When plugin in
a Monitor a list of possible Resolutions+Framerate combinations is
created for xrandr and other userspace (I guess by atomic checks? but
I don't know).

Hi,

I would not think so, but I hope to be corrected if I'm wrong.

My belief is that the driver collects a list of modes from EDID, some
standard modes, and maybe some other hardcoded modes, and then
validates each entry against all the known limitations like vertical
and horizontal frequency limits, discarding modes that do not fit.

Not all limitations are known during that phase, which is why KMS
property "link-status" exists. When userspace actually programs a mode
(not a TEST_ONLY commit), the link training may fail. The kernel prunes
the mode from the list and sets the link status property to signal
failure, and sends a hotplug uevent. Userspace needs to re-check the
mode list and try again.

That is a generic escape hatch for when TEST_ONLY commit succeeds, but
in reality the hardware cannot do it, you just cannot know until you
actually try for real. It causes end user visible flicker if it happens
on an already running connector, but since it usually happens when
turning a connector on to begin with, there is no flicker to be seen,
just a small delay in finding a mode that works.
  

During this drm
properties are already considered, which is no problem atm because as
far as i can tell there is currently no drm property that would make
a certain Resolutions+Framerate combination unreachable that would be
possible with everything on default.

I would not expect KMS properties to be considered at all. It would
reject modes that are actually possible if the some KMS properties were
changed. So at least going forward, current KMS property values cannot
factor in.

At least the debugfs variable "force_yuv420_output" did change the
available modes here:
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165
before my patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf

Hi,

debugfs is not proper UAPI, so we can just ignore it. Display servers
cannot be expected to poke in debugfs. Debugfs is not even supposed to
exist in production systems, but I'm sure people use it for hacking
stuff. But that's all it is for: developer testing and hacking.

e.g. Ubuntu has it active by default, but only read (and writable) by root.

Hi,

that's normal, yes. Root can do damage anyway, and it's useful for
debugging. KMS clients OTOH often do not run as root.
  


F

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-07-05 Thread Werner Sembach


Am 01.07.21 um 15:24 schrieb Pekka Paalanen:
> On Thu, 1 Jul 2021 14:50:13 +0200
> Werner Sembach  wrote:
>
>> Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
>>
>>> On Wed, 30 Jun 2021 11:20:18 +0200
>>> Werner Sembach  wrote:
>>>  
>>>> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
>>>>  
>>>>> On Tue, 29 Jun 2021 13:39:18 +0200
>>>>> Werner Sembach  wrote:
>>>>>
>>>>>> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
>>>>>>> On Tue, 29 Jun 2021 08:12:54 +
>>>>>>> Simon Ser  wrote:
>>>>>>>   
>>>>>>>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen 
>>>>>>>>  wrote:
>>>>>>>>   
>>>>>>>>> yes, I think this makes sense, even if it is a property that one can't
>>>>>>>>> tell for sure what it does before hand.
>>>>>>>>>
>>>>>>>>> Using a pair of properties, preference and active, to ask for 
>>>>>>>>> something
>>>>>>>>> and then check what actually worked is good for reducing the
>>>>>>>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>>>>>>>> test different KMS configurations. Userspace has a better chance of
>>>>>>>>> finding a configuration that is possible.
>>>>>>>>>
>>>>>>>>> OTOH, this has the problem than in UI one cannot tell the user in
>>>>>>>>> advance which options are truly possible. Given that KMS properties 
>>>>>>>>> are
>>>>>>>>> rarely completely independent, and in this case known to depend on
>>>>>>>>> several other KMS properties, I think it is good enough to know after
>>>>>>>>> the fact.
>>>>>>>>>
>>>>>>>>> If a driver does not use what userspace prefers, there is no way to
>>>>>>>>> understand why, or what else to change to make it happen. That problem
>>>>>>>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>>>>>>>> but only a yes/no.
>>>>>>>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only 
>>>>>>>> changing one
>>>>>>>> property at a time), user-space can discover which property makes the 
>>>>>>>> atomic
>>>>>>>> commit fail.
>>>>>>> That works if the properties are independent of each other. Color
>>>>>>> range, color format, bpc and more may all be interconnected,
>>>>>>> allowing only certain combinations to work.
>>>>>>>
>>>>>>> If all these properties have "auto" setting too, then it would be
>>>>>>> possible to probe each property individually, but that still does not
>>>>>>> tell which combinations are valid.
>>>>>>>
>>>>>>> If you probe towards a certain configuration by setting the properties
>>>>>>> one by one, then depending on the order you pick the properties, you
>>>>>>> may come to a different conclusion on which property breaks the
>>>>>>> configuration.
>>>>>> My mind crossed another point that must be considered: When plugin in
>>>>>> a Monitor a list of possible Resolutions+Framerate combinations is
>>>>>> created for xrandr and other userspace (I guess by atomic checks? but
>>>>>> I don't know).
>>>>> Hi,
>>>>>
>>>>> I would not think so, but I hope to be corrected if I'm wrong.
>>>>>
>>>>> My belief is that the driver collects a list of modes from EDID, some
>>>>> standard modes, and maybe some other hardcoded modes, and then
>>>>> validates each entry against all the known limitations like vertical
>>>>> and horizontal frequency limits, discarding modes that do not fit.
>>>>>
>>>>> Not all limitations are known during that phase, which is why KMS
>>>>> property "link-status" exists. When userspace actually programs a mode
>>>>> (not a TEST_ONLY commit), the link training may fail. The kernel prun

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-07-01 Thread Werner Sembach
Am 01.07.21 um 10:07 schrieb Pekka Paalanen:

> On Wed, 30 Jun 2021 11:20:18 +0200
> Werner Sembach  wrote:
>
>> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
>>
>>> On Tue, 29 Jun 2021 13:39:18 +0200
>>> Werner Sembach  wrote:
>>>  
>>>> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:  
>>>>> On Tue, 29 Jun 2021 08:12:54 +
>>>>> Simon Ser  wrote:
>>>>> 
>>>>>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen 
>>>>>>  wrote:
>>>>>> 
>>>>>>> yes, I think this makes sense, even if it is a property that one can't
>>>>>>> tell for sure what it does before hand.
>>>>>>>
>>>>>>> Using a pair of properties, preference and active, to ask for something
>>>>>>> and then check what actually worked is good for reducing the
>>>>>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>>>>>> test different KMS configurations. Userspace has a better chance of
>>>>>>> finding a configuration that is possible.
>>>>>>>
>>>>>>> OTOH, this has the problem than in UI one cannot tell the user in
>>>>>>> advance which options are truly possible. Given that KMS properties are
>>>>>>> rarely completely independent, and in this case known to depend on
>>>>>>> several other KMS properties, I think it is good enough to know after
>>>>>>> the fact.
>>>>>>>
>>>>>>> If a driver does not use what userspace prefers, there is no way to
>>>>>>> understand why, or what else to change to make it happen. That problem
>>>>>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>>>>>> but only a yes/no.  
>>>>>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing 
>>>>>> one
>>>>>> property at a time), user-space can discover which property makes the 
>>>>>> atomic
>>>>>> commit fail.  
>>>>> That works if the properties are independent of each other. Color
>>>>> range, color format, bpc and more may all be interconnected,
>>>>> allowing only certain combinations to work.
>>>>>
>>>>> If all these properties have "auto" setting too, then it would be
>>>>> possible to probe each property individually, but that still does not
>>>>> tell which combinations are valid.
>>>>>
>>>>> If you probe towards a certain configuration by setting the properties
>>>>> one by one, then depending on the order you pick the properties, you
>>>>> may come to a different conclusion on which property breaks the
>>>>> configuration.  
>>>> My mind crossed another point that must be considered: When plugin in
>>>> a Monitor a list of possible Resolutions+Framerate combinations is
>>>> created for xrandr and other userspace (I guess by atomic checks? but
>>>> I don't know).  
>>> Hi,
>>>
>>> I would not think so, but I hope to be corrected if I'm wrong.
>>>
>>> My belief is that the driver collects a list of modes from EDID, some
>>> standard modes, and maybe some other hardcoded modes, and then
>>> validates each entry against all the known limitations like vertical
>>> and horizontal frequency limits, discarding modes that do not fit.
>>>
>>> Not all limitations are known during that phase, which is why KMS
>>> property "link-status" exists. When userspace actually programs a mode
>>> (not a TEST_ONLY commit), the link training may fail. The kernel prunes
>>> the mode from the list and sets the link status property to signal
>>> failure, and sends a hotplug uevent. Userspace needs to re-check the
>>> mode list and try again.
>>>
>>> That is a generic escape hatch for when TEST_ONLY commit succeeds, but
>>> in reality the hardware cannot do it, you just cannot know until you
>>> actually try for real. It causes end user visible flicker if it happens
>>> on an already running connector, but since it usually happens when
>>> turning a connector on to begin with, there is no flicker to be seen,
>>> just a small delay in finding a mode that works.
>>>  
>>>> During this drm
>>>> propert

Re: [Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-07-01 Thread Werner Sembach


Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
> On Wed, 30 Jun 2021 11:42:10 +0200
> Werner Sembach  wrote:
>
>> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
>>> On Tue, 29 Jun 2021 13:02:05 +0200
>>> Werner Sembach  wrote:
>>>  
>>>> Am 28.06.21 um 19:03 schrieb Werner Sembach:  
>>>>> Am 18.06.21 um 11:11 schrieb Werner Sembach:  
>>>>>> 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 
>>>>>> ---
>>>>>>   drivers/gpu/drm/drm_connector.c | 51 +
>>>>>>   include/drm/drm_connector.h |  8 ++
>>>>>>   2 files changed, 59 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/drm_connector.c 
>>>>>> b/drivers/gpu/drm/drm_connector.c
>>>>>> index da39e7ff6965..943f6b61053b 100644
>>>>>> --- a/drivers/gpu/drm/drm_connector.c
>>>>>> +++ b/drivers/gpu/drm/drm_connector.c
>>>>>> @@ -1197,6 +1197,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.
>>>>>> + *  
>>>>> Regarding "on the cable" and dithering: As far as I can tell, what the 
>>>>> dithering option does, is setting a hardware
>>>>> register here:
>>>>>
>>>>> - 
>>>>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
>>>>>
>>>>> - 
>>>>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
>>>>>
>>>>> So dithering seems to be calculated by fixed purpose hardware/firmware 
>>>>> outside of the driver?
>>>>>
>>>>> The Intel driver does not seem to set a target bpc/bpp for this hardware 
>>>>> so I guess it defaults to 6 or 8 bpc?  
>>>> Never mind it does. This switch-case does affect the dithering output:
>>>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537
>>>>   
>>> Hi,
>>>
>>> I obviously do not know the intel driver or hardware at all, but
>>> to me that just looks like translating from bits per pixel to bits per
>>> channel in RGB mapping?  
>> No, if i understand the documentation correctly: Writing bit depth here 
>> with dithering enabled sets the dithering target bpc.
>>>  
>>>> As found in this documentation p.548:
>>>> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf
>>>>
>>>> So max bpc and active bpc are affecting/affected by the bpc after 
>>>> dithering.  
>>> By definition, if the cable carries N bpc, then dither

[Intel-gfx] [PATCH v5 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context

2021-06-30 Thread Werner Sembach
Add "Broadcast RGB" to general drm context so that more drivers besides
i915 and gma500 can implement it without duplicating code.

Userspace can use this property to tell the graphic driver to use full or
limited color range for a given connector, overwriting the default
behaviour/automatic detection.

Possible options are:
- Automatic (default/current behaviour)
- Full
- Limited 16:235

In theory the driver should be able to automatically detect the monitors
capabilities, but because of flawed standard implementations in Monitors,
this might fail. In this case a manual overwrite is required to not have
washed out colors or lose details in very dark or bright scenes.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_atomic_helper.c |  4 +++
 drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
 drivers/gpu/drm/drm_connector.c | 46 +
 include/drm/drm_connector.h | 16 ++
 4 files changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 90d62f305257..0c89d32efbd0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->preferred_color_format !=
new_connector_state->preferred_color_format)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->preferred_color_range !=
+   new_connector_state->preferred_color_range)
+   new_crtc_state->connectors_changed = true;
}
 
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index c536f5e22016..c589bb1a8163 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->max_requested_bpc = val;
} else if (property == connector->preferred_color_format_property) {
state->preferred_color_format = val;
+   } else if (property == connector->preferred_color_range_property) {
+   state->preferred_color_range = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->max_requested_bpc;
} else if (property == connector->preferred_color_format_property) {
*val = state->preferred_color_format;
+   } else if (property == connector->preferred_color_range_property) {
+   *val = state->preferred_color_range;
} 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 67dd59b12258..20ae2e6d907b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -905,6 +905,12 @@ static const struct drm_prop_enum_list 
drm_active_color_format_enum_list[] = {
{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
 };
 
+static const struct drm_prop_enum_list drm_preferred_color_range_enum_list[] = 
{
+   { DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
+   { DRM_MODE_COLOR_RANGE_FULL, "Full" },
+   { DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
+};
+
 static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
{ DRM_MODE_COLOR_RANGE_UNSET, "Not Applicable" },
{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
@@ -1246,6 +1252,15 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * property. Possible values are "not applicable", "rgb", "ycbcr444",
  * "ycbcr422", and "ycbcr420".
  *
+ * Broadcast RGB:
+ * This property is used by userspace to change the used color range. This
+ * property affects the RGB color format as well as the Y'CbCr color
+ * formats, if the driver supports both full and limited Y'CbCr. Drivers to
+ * use the function drm_connector_attach_preferred_color_format_property()
+ * to create and attach the property to the connector during
+ * initialization. Possible values are "Automatic", "Full", and "Limited
+ * 16:235".
+ *
  * active color range:
  * This read-only property tells userspace the color range actually used by
  * the hardware d

[Intel-gfx] [PATCH v5 11/17] drm/i915/display: Add handling for new "active color range" property

2021-06-30 Thread Werner Sembach
This commit implements the "active color range" drm property for the Intel
GPU driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 7 +++
 drivers/gpu/drm/i915/display/intel_dp.c  | 1 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c  | 5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c| 1 +
 4 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index be38f7148285..b0bcb42a97fc 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10940,9 +10940,16 @@ static int intel_atomic_commit(struct drm_device *dev,

drm_connector_set_active_color_format_property(connector,

convert_intel_output_format_into_drm_color_format(
new_crtc_state->output_format));
+   drm_connector_set_active_color_range_property(connector,
+   new_crtc_state->limited_color_range ||
+   new_crtc_state->output_format != 
INTEL_OUTPUT_FORMAT_RGB ?
+   DRM_MODE_COLOR_RANGE_LIMITED_16_235 :
+   DRM_MODE_COLOR_RANGE_FULL);
} else {
drm_connector_set_active_bpc_property(connector, 0);

drm_connector_set_active_color_format_property(connector, 0);
+   drm_connector_set_active_color_range_property(connector,
+ 
DRM_MODE_COLOR_RANGE_UNSET);
}
}
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6b85bcdeb238..fd33f753244d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4688,6 +4688,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct 
drm_connector *connect
intel_attach_force_audio_property(connector);
 
intel_attach_broadcast_rgb_property(connector);
+   drm_connector_attach_active_color_range_property(connector);
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 3e4237df3360..cb876175258f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -861,6 +861,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_color_format_property)
drm_connector_attach_active_color_format_property(connector);
 
+   connector->active_color_range_property =
+   intel_dp->attached_connector->base.active_color_range_property;
+   if (connector->active_color_range_property)
+   drm_connector_attach_active_color_range_property(connector);
+
return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 367aba57b55f..3ee25e0cc3b9 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2505,6 +2505,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
 
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+   drm_connector_attach_active_color_range_property(connector);
intel_attach_aspect_ratio_property(connector);
 
intel_attach_hdmi_colorspace_property(connector);
-- 
2.25.1

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


[Intel-gfx] [PATCH v5 16/17] drm/i915/display: Use the general "Broadcast RGB" implementation

2021-06-30 Thread Werner Sembach
Change from the i915 specific "Broadcast RGB" drm property implementation
to the general one.

This commit delete all traces of the former "Broadcast RGB" implementation
and add a new one using the new driver agnoistic functions an variables.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_atomic.c   |  8 --
 .../gpu/drm/i915/display/intel_connector.c| 28 ---
 .../gpu/drm/i915/display/intel_connector.h|  1 -
 .../drm/i915/display/intel_display_types.h|  8 --
 drivers/gpu/drm/i915/display/intel_dp.c   |  9 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  6 +++-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  8 ++
 drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   |  1 -
 9 files changed, 12 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index b4e7ac51aa31..f8d5a0e287b0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -63,8 +63,6 @@ int intel_digital_connector_atomic_get_property(struct 
drm_connector *connector,
 
if (property == dev_priv->force_audio_property)
*val = intel_conn_state->force_audio;
-   else if (property == dev_priv->broadcast_rgb_property)
-   *val = intel_conn_state->broadcast_rgb;
else {
drm_dbg_atomic(_priv->drm,
   "Unknown property [PROP:%d:%s]\n",
@@ -99,11 +97,6 @@ int intel_digital_connector_atomic_set_property(struct 
drm_connector *connector,
return 0;
}
 
-   if (property == dev_priv->broadcast_rgb_property) {
-   intel_conn_state->broadcast_rgb = val;
-   return 0;
-   }
-
drm_dbg_atomic(_priv->drm, "Unknown property [PROP:%d:%s]\n",
   property->base.id, property->name);
return -EINVAL;
@@ -134,7 +127,6 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
 * up in a modeset.
 */
if (new_conn_state->force_audio != old_conn_state->force_audio ||
-   new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.colorspace != old_conn_state->base.colorspace 
||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c 
b/drivers/gpu/drm/i915/display/intel_connector.c
index 9bed1ccecea0..89f0edf19182 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -241,34 +241,6 @@ intel_attach_force_audio_property(struct drm_connector 
*connector)
drm_object_attach_property(>base, prop, 0);
 }
 
-static const struct drm_prop_enum_list broadcast_rgb_names[] = {
-   { INTEL_BROADCAST_RGB_AUTO, "Automatic" },
-   { INTEL_BROADCAST_RGB_FULL, "Full" },
-   { INTEL_BROADCAST_RGB_LIMITED, "Limited 16:235" },
-};
-
-void
-intel_attach_broadcast_rgb_property(struct drm_connector *connector)
-{
-   struct drm_device *dev = connector->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct drm_property *prop;
-
-   prop = dev_priv->broadcast_rgb_property;
-   if (prop == NULL) {
-   prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
-  "Broadcast RGB",
-  broadcast_rgb_names,
-  ARRAY_SIZE(broadcast_rgb_names));
-   if (prop == NULL)
-   return;
-
-   dev_priv->broadcast_rgb_property = prop;
-   }
-
-   drm_object_attach_property(>base, prop, 0);
-}
-
 void
 intel_attach_aspect_ratio_property(struct drm_connector *connector)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_connector.h 
b/drivers/gpu/drm/i915/display/intel_connector.h
index 661a37a3c6d8..f3058a035476 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.h
+++ b/drivers/gpu/drm/i915/display/intel_connector.h
@@ -28,7 +28,6 @@ int intel_connector_update_modes(struct drm_connector 
*connector,
 struct edid *edid);
 int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *adapter);
 void intel_attach_force_audio_property(struct drm_connector *connector);
-void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
 void intel_attach_aspect_ratio_property(struct drm_connector *connector);
 void intel_attach_hdmi_colorspace_property(struct drm_connector *connector);
 void intel_atta

[Intel-gfx] [PATCH v5 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-06-30 Thread Werner Sembach
Add a new general drm property "preferred color format" which can be used
by userspace to tell the graphic drivers to which color format to use.

Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (not supported by both amdgpu and i915)
- ycbcr420

In theory the auto option should choose the best available option for the
current setup, but because of bad internal conversion some monitors look
better with rgb and some with ycbcr444.

Also, because of bad shielded connectors and/or cables, it might be
preferable to use the less bandwidth heavy ycbcr422 and ycbcr420 formats
for a signal that is less deceptible to interference.

In the future, automatic color calibration for screens might also depend on
this option being available.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_atomic_helper.c |  4 +++
 drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
 drivers/gpu/drm/drm_connector.c | 50 -
 include/drm/drm_connector.h | 17 ++
 4 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index bc3487964fb5..90d62f305257 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -687,6 +687,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->max_requested_bpc !=
new_connector_state->max_requested_bpc)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->preferred_color_format !=
+   new_connector_state->preferred_color_format)
+   new_crtc_state->connectors_changed = true;
}
 
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 438e9585b225..c536f5e22016 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -796,6 +796,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
   fence_ptr);
} else if (property == connector->max_bpc_property) {
state->max_requested_bpc = val;
+   } else if (property == connector->preferred_color_format_property) {
+   state->preferred_color_format = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -873,6 +875,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->preferred_color_format_property) {
+   *val = state->preferred_color_format;
} 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 ebfdd17a7f59..67dd59b12258 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -889,6 +889,14 @@ static const struct drm_prop_enum_list 
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native,  "Native"}, /* DP */
 };
 
+static const struct drm_prop_enum_list drm_preferred_color_format_enum_list[] 
= {
+   { 0, "auto" },
+   { DRM_COLOR_FORMAT_RGB444, "rgb" },
+   { DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
+   { DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
+   { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
+};
+
 static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
{ 0, "not applicable" },
{ DRM_COLOR_FORMAT_RGB444, "rgb" },
@@ -1220,11 +1228,20 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * Drivers shall use drm_connector_attach_active_bpc_property() to install
  * this property. A value of 0 means "not applicable".
  *
+ * preferred color format:
+ * This property is used by userspace to change the used color format. When
+ * used the driver will use the selected format if valid for the hardware,
+ * sink, and current resolution and refresh rate combination. Drivers to
+ * use the function drm_connector_attach_preferred_color_format_property()
+ * to create and attach the property to the connector during
+ * initialization. Possible values are "auto", "rgb", "ycbcr444",
+ * "ycbcr422&qu

[Intel-gfx] [PATCH v5 13/17] drm/amd/display: Add handling for new "preferred color format" property

2021-06-30 Thread Werner Sembach
This commit implements the "preferred color format" drm property for the
AMD GPU driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 +++
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +++
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b4acedac1ac9..02a5809d4993 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5346,15 +5346,32 @@ static void 
fill_stream_properties_from_drm_display_mode(
timing_out->h_border_right = 0;
timing_out->v_border_top = 0;
timing_out->v_border_bottom = 0;
-   /* TODO: un-hardcode */
-   if (drm_mode_is_420_only(info, mode_in)
-   || (drm_mode_is_420_also(info, mode_in) && 
aconnector->force_yuv420_output))
+
+   if (connector_state
+   && (connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB420
+   || aconnector->force_yuv420_output) && 
drm_mode_is_420(info, mode_in))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
-   else if ((connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
-   && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+   else if (connector_state
+   && connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB444
+   && connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
-   else
+   else if (connector_state
+   && connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_RGB444
+   && !drm_mode_is_420_only(info, mode_in))
timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
+   else
+   /*
+* connector_state->preferred_color_format not possible
+* || connector_state->preferred_color_format == 0 (auto)
+* || connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB422
+*/
+   if (drm_mode_is_420_only(info, mode_in))
+   timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
+   else if ((connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
+   && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+   timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
+   else
+   timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
 
timing_out->timing_3d_format = TIMING_3D_FORMAT_NONE;
timing_out->display_color_depth = convert_color_depth_from_display_info(
@@ -7756,6 +7773,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   
drm_connector_attach_preferred_color_format_property(>base);

drm_connector_attach_active_color_format_property(>base);

drm_connector_attach_active_color_range_property(>base);
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index b5d57bbbdd20..2563788ba95a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -413,6 +413,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(>base, 8, 
16);
 
+   connector->preferred_color_format_property = 
master->base.preferred_color_format_property;
+   if (connector->preferred_color_format_property)
+   
drm_connector_attach_preferred_color_format_property(>base);
+
connector->active_color_format_property = 
master->base.active_color_format_property;
if (connector->active_color_format_property)

drm_connector_attach_active_color_format_property(>base);
-- 
2.25.1

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


[Intel-gfx] [PATCH v5 04/17] drm/amd/display: Add handling for new "active bpc" property

2021-06-30 Thread Werner Sembach
This commit implements the "active bpc" drm property for the AMD GPU
driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f4abb5f215d1..d984de82ae63 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7708,8 +7708,10 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
adev->mode_info.underscan_vborder_property,
0);
 
-   if (!aconnector->mst_port)
+   if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
+   drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   }
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
aconnector->base.state->max_bpc = (connector_type == 
DRM_MODE_CONNECTOR_eDP) ? 16 : 8;
@@ -9078,6 +9080,26 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
mutex_unlock(>dc_lock);
}
 
+   /* Extract information from crtc to communicate it to userspace as 
connector properties */
+   for_each_new_connector_in_state(state, connector, new_con_state, i) {
+   struct drm_crtc *crtc = new_con_state->crtc;
+   struct dc_stream_state *stream;
+
+   if (crtc) {
+   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
+   dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+   stream = dm_new_crtc_state->stream;
+
+   if (stream)
+   drm_connector_set_active_bpc_property(connector,
+   stream->timing.flags.DSC ?
+   
stream->timing.dsc_cfg.bits_per_pixel / 16 / 3 :
+   convert_dc_color_depth_into_bpc(
+   
stream->timing.display_color_depth));
+   } else
+   drm_connector_set_active_bpc_property(connector, 0);
+   }
+
/* Count number of newly disabled CRTCs for dropping PM refs later. */
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
  new_crtc_state, i) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 5568d4e518e6..0cf38743ec47 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -409,6 +409,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->max_bpc_property)
drm_connector_attach_max_bpc_property(connector, 8, 16);
 
+   connector->active_bpc_property = master->base.active_bpc_property;
+   if (connector->active_bpc_property)
+   drm_connector_attach_active_bpc_property(>base, 8, 
16);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1

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


[Intel-gfx] [PATCH v5 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property

2021-06-30 Thread Werner Sembach
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 14 +++---
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  4 
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 02a5809d4993..80d5a11fb0c5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5247,7 +5247,8 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
 }
 
 static enum dc_color_space
-get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
+get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
+  enum drm_mode_color_range preferred_color_range)
 {
enum dc_color_space color_space = COLOR_SPACE_SRGB;
 
@@ -5278,7 +5279,10 @@ get_output_color_space(const struct dc_crtc_timing 
*dc_crtc_timing)
}
break;
case PIXEL_ENCODING_RGB:
-   color_space = COLOR_SPACE_SRGB;
+   if (preferred_color_range == 
DRM_MODE_COLOR_RANGE_LIMITED_16_235)
+   color_space = COLOR_SPACE_SRGB_LIMITED;
+   else
+   color_space = COLOR_SPACE_SRGB;
break;
 
default:
@@ -5424,7 +5428,10 @@ static void fill_stream_properties_from_drm_display_mode(
 
timing_out->aspect_ratio = get_aspect_ratio(mode_in);
 
-   stream->output_color_space = get_output_color_space(timing_out);
+   stream->output_color_space = get_output_color_space(timing_out,
+   connector_state ?
+   
connector_state->preferred_color_range :
+   
DRM_MODE_COLOR_RANGE_UNSET);
 
stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
@@ -7775,6 +7782,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
drm_connector_attach_active_bpc_property(>base, 8, 
16);

drm_connector_attach_preferred_color_format_property(>base);

drm_connector_attach_active_color_format_property(>base);
+   
drm_connector_attach_preferred_color_range_property(>base);

drm_connector_attach_active_color_range_property(>base);
}
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 2563788ba95a..80e1389fd0ec 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -421,6 +421,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_color_format_property)

drm_connector_attach_active_color_format_property(>base);
 
+   connector->preferred_color_range_property = 
master->base.preferred_color_range_property;
+   if (connector->preferred_color_range_property)
+   
drm_connector_attach_preferred_color_range_property(>base);
+
connector->active_color_range_property = 
master->base.active_color_range_property;
if (connector->active_color_range_property)

drm_connector_attach_active_color_range_property(>base);
-- 
2.25.1

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


[Intel-gfx] [PATCH v5 14/17] drm/i915/display: Add handling for new "preferred color format" property

2021-06-30 Thread Werner Sembach
This commit implements the "preferred color format" drm property for the
Intel GPU driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c   | 6 ++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index fd33f753244d..29bb181ec4be 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -616,9 +616,12 @@ intel_dp_output_format(struct drm_connector *connector,
 {
struct intel_dp *intel_dp = 
intel_attached_dp(to_intel_connector(connector));
const struct drm_display_info *info = >display_info;
+   const struct drm_connector_state *connector_state = connector->state;
 
if (!connector->ycbcr_420_allowed ||
-   !drm_mode_is_420_only(info, mode))
+   !(drm_mode_is_420_only(info, mode) ||
+   (drm_mode_is_420_also(info, mode) && connector_state &&
+   connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB420)))
return INTEL_OUTPUT_FORMAT_RGB;
 
if (intel_dp->dfp.rgb_to_ycbcr &&
@@ -4692,10 +4695,12 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
+   drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
} else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
+   drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
}
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index cb876175258f..67f0fb649876 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -856,6 +856,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(connector, 6, 12);
 
+   connector->preferred_color_format_property =
+   
intel_dp->attached_connector->base.preferred_color_format_property;
+   if (connector->preferred_color_format_property)
+   drm_connector_attach_preferred_color_format_property(connector);
+
connector->active_color_format_property =
intel_dp->attached_connector->base.active_color_format_property;
if (connector->active_color_format_property)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 3ee25e0cc3b9..a7b85cd13227 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2153,6 +2153,11 @@ static int intel_hdmi_compute_output_format(struct 
intel_encoder *encoder,
crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
}
 
+   if (connector->ycbcr_420_allowed &&
+   conn_state->preferred_color_format == DRM_COLOR_FORMAT_YCRCB420 &&
+   drm_mode_is_420_also(>display_info, adjusted_mode))
+   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+
ret = intel_hdmi_compute_clock(encoder, crtc_state);
if (ret) {
if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420 &&
@@ -2517,6 +2522,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
drm_connector_attach_active_bpc_property(connector, 8, 12);
+   drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
}
 }
-- 
2.25.1

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


[Intel-gfx] [PATCH v5 08/17] drm/i915/display: Add handling for new "active color format" property

2021-06-30 Thread Werner Sembach
This commit implements the "active color format" drm property for the Intel
GPU driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 22 +++-
 drivers/gpu/drm/i915/display/intel_dp.c  |  2 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c|  1 +
 4 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 1b63d1404d06..be38f7148285 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10609,6 +10609,21 @@ static void 
intel_atomic_prepare_plane_clear_colors(struct intel_atomic_state *s
}
 }
 
+static int convert_intel_output_format_into_drm_color_format(enum 
intel_output_format output_format)
+{
+   switch (output_format) {
+   case INTEL_OUTPUT_FORMAT_RGB:
+   return DRM_COLOR_FORMAT_RGB444;
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   return DRM_COLOR_FORMAT_YCRCB420;
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   return DRM_COLOR_FORMAT_YCRCB444;
+   default:
+   break;
+   }
+   return 0;
+}
+
 static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 {
struct drm_device *dev = state->base.dev;
@@ -10922,8 +10937,13 @@ static int intel_atomic_commit(struct drm_device *dev,
new_crtc_state->dsc.compression_enable ?
new_crtc_state->dsc.compressed_bpp / 3 :
new_crtc_state->pipe_bpp / 3);
-   } else
+   
drm_connector_set_active_color_format_property(connector,
+   
convert_intel_output_format_into_drm_color_format(
+   new_crtc_state->output_format));
+   } else {
drm_connector_set_active_bpc_property(connector, 0);
+   
drm_connector_set_active_color_format_property(connector, 0);
+   }
}
 
drm_atomic_state_get(>base);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 815bc313b954..6b85bcdeb238 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4691,9 +4691,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
+   drm_connector_attach_active_color_format_property(connector);
} else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_color_format_property(connector);
}
 
/* Register HDMI colorspace for case of lspcon */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 16bfc59570a5..3e4237df3360 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -856,6 +856,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(connector, 6, 12);
 
+   connector->active_color_format_property =
+   intel_dp->attached_connector->base.active_color_format_property;
+   if (connector->active_color_format_property)
+   drm_connector_attach_active_color_format_property(connector);
+
return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 9160e21ac9d6..367aba57b55f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2516,6 +2516,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
drm_connector_attach_active_bpc_property(connector, 8, 12);
+   drm_connector_attach_active_color_format_property(connector);
}
 }
 
-- 
2.25.1

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


[Intel-gfx] [PATCH v5 10/17] drm/amd/display: Add handling for new "active color range" property

2021-06-30 Thread Werner Sembach
This commit implements the "active color range" drm property for the AMD
GPU driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 +++
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 098f3d53e681..b4acedac1ac9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6728,6 +6728,33 @@ static int 
convert_dc_pixel_encoding_into_drm_color_format(
return 0;
 }
 
+static int convert_dc_color_space_into_drm_mode_color_range(enum 
dc_color_space color_space)
+{
+   if (color_space == COLOR_SPACE_SRGB ||
+   color_space == COLOR_SPACE_XR_RGB ||
+   color_space == COLOR_SPACE_MSREF_SCRGB ||
+   color_space == COLOR_SPACE_2020_RGB_FULLRANGE ||
+   color_space == COLOR_SPACE_ADOBERGB ||
+   color_space == COLOR_SPACE_DCIP3 ||
+   color_space == COLOR_SPACE_DOLBYVISION ||
+   color_space == COLOR_SPACE_YCBCR601 ||
+   color_space == COLOR_SPACE_XV_YCC_601 ||
+   color_space == COLOR_SPACE_YCBCR709 ||
+   color_space == COLOR_SPACE_XV_YCC_709 ||
+   color_space == COLOR_SPACE_2020_YCBCR ||
+   color_space == COLOR_SPACE_YCBCR709_BLACK ||
+   color_space == COLOR_SPACE_DISPLAYNATIVE ||
+   color_space == COLOR_SPACE_APPCTRL ||
+   color_space == COLOR_SPACE_CUSTOMPOINTS)
+   return DRM_MODE_COLOR_RANGE_FULL;
+   if (color_space == COLOR_SPACE_SRGB_LIMITED ||
+   color_space == COLOR_SPACE_2020_RGB_LIMITEDRANGE ||
+   color_space == COLOR_SPACE_YCBCR601_LIMITED ||
+   color_space == COLOR_SPACE_YCBCR709_LIMITED)
+   return DRM_MODE_COLOR_RANGE_LIMITED_16_235;
+   return DRM_MODE_COLOR_RANGE_UNSET;
+}
+
 static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
  struct drm_crtc_state *crtc_state,
  struct drm_connector_state 
*conn_state)
@@ -7730,6 +7757,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8, 
16);

drm_connector_attach_active_color_format_property(>base);
+   
drm_connector_attach_active_color_range_property(>base);
}
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
@@ -9118,10 +9146,15 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)

drm_connector_set_active_color_format_property(connector,

convert_dc_pixel_encoding_into_drm_color_format(

dm_new_crtc_state->stream->timing.pixel_encoding));
+   
drm_connector_set_active_color_range_property(connector,
+   
convert_dc_color_space_into_drm_mode_color_range(
+   
dm_new_crtc_state->stream->output_color_space));
}
} else {
drm_connector_set_active_bpc_property(connector, 0);

drm_connector_set_active_color_format_property(connector, 0);
+   drm_connector_set_active_color_range_property(connector,
+ 
DRM_MODE_COLOR_RANGE_UNSET);
}
}
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 13151d13aa73..b5d57bbbdd20 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -417,6 +417,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_color_format_property)

drm_connector_attach_active_color_format_property(>base);
 
+   connector->active_color_range_property = 
master->base.active_color_range_property;
+   if (connector->active_color_range_property)
+   
drm_connector_attach_active_color_range_property(>base);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1

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


[Intel-gfx] [PATCH v5 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

2021-06-30 Thread Werner Sembach
Add a new general drm property "active color range" which can be used by
graphic drivers to report the used color range back to userspace.

There was no way to check which color range got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor and what the default behaviour of the used driver is. This
property helps eliminating the guessing at this point.

In the future, automatic color calibration for screens might also depend on
this information being available.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_connector.c | 61 +
 include/drm/drm_connector.h | 27 +++
 2 files changed, 88 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 075bdc08d5c3..ebfdd17a7f59 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -897,6 +897,12 @@ static const struct drm_prop_enum_list 
drm_active_color_format_enum_list[] = {
{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
 };
 
+static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
+   { DRM_MODE_COLOR_RANGE_UNSET, "Not Applicable" },
+   { DRM_MODE_COLOR_RANGE_FULL, "Full" },
+   { DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
+};
+
 DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 drm_dp_subconnector_enum_list)
 
@@ -1223,6 +1229,15 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * property. Possible values are "not applicable", "rgb", "ycbcr444",
  * "ycbcr422", and "ycbcr420".
  *
+ * active color range:
+ * This read-only property tells userspace the color range actually used by
+ * the hardware display engine "on the cable" on a connector. The chosen
+ * value depends on hardware capabilities of the monitor and the used color
+ * format. Drivers shall use
+ * drm_connector_attach_active_color_range_property() to install this
+ * property. Possible values are "Not Applicable", "Full", and "Limited
+ * 16:235".
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -2268,6 +2283,52 @@ void 
drm_connector_set_active_color_format_property(struct drm_connector *connec
 }
 EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
 
+/**
+ * drm_connector_attach_active_color_range_property - attach "active color 
range" property
+ * @connector: connector to attach active color range property on.
+ *
+ * This is used to check the applied color range on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_range_property(struct drm_connector 
*connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   if (!connector->active_color_range_property) {
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, 
"active color range",
+   
drm_active_color_range_enum_list,
+   
ARRAY_SIZE(drm_active_color_range_enum_list));
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_color_range_property = prop;
+   }
+
+   drm_object_attach_property(>base, prop, 
DRM_MODE_COLOR_RANGE_UNSET);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_range_property);
+
+/**
+ * drm_connector_set_active_color_range_property - sets the active color range 
property for a
+ * connector
+ * @connector: drm connector
+ * @active_color_range: color range for the connector currently active "on the 
cable"
+ *
+ * Should be used by atomic drivers to update the active color range over a 
connector.
+ */
+void drm_connector_set_active_color_range_property(struct drm_connector 
*connector,
+  enum drm_mode_color_range 
active_color_range)
+{
+   drm_object_property_set_value(>base, 
connector->active_color_range_property,
+ active_color_range);
+}
+EXPORT_SYMBOL(drm_connector_set_active_color_range_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach 
"HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 8a5197f14e87..5ef4bb270f71 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -648,6 +648,24 @@ struct drm_tv_connector_state {
unsigned int hue;
 };
 
+/**
+ * enum drm_mode_color_range - color_range info for _connector
+ *
+ * This enum is used to represent full or limited color range on

[Intel-gfx] [PATCH v5 06/17] drm/uAPI: Add "active color format" drm property as feedback for userspace

2021-06-30 Thread Werner Sembach
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.

There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor, the GPU, and the connection used and what the default
behaviour of the used driver is (e.g. amdgpu prefers YCbCr 4:4:4 while i915
prefers RGB). This property helps eliminating the guessing on this point.

In the future, automatic color calibration for screens might also depend on
this information being available.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_connector.c | 63 +
 include/drm/drm_connector.h |  9 +
 2 files changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 6461d00e8e49..075bdc08d5c3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -889,6 +889,14 @@ static const struct drm_prop_enum_list 
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native,  "Native"}, /* DP */
 };
 
+static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
+   { 0, "not applicable" },
+   { DRM_COLOR_FORMAT_RGB444, "rgb" },
+   { DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
+   { DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
+   { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
+};
+
 DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 drm_dp_subconnector_enum_list)
 
@@ -1206,6 +1214,15 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * Drivers shall use drm_connector_attach_active_bpc_property() to install
  * this property. A value of 0 means "not applicable".
  *
+ * active color format:
+ * This read-only property tells userspace the color format 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. Drivers shall use
+ * drm_connector_attach_active_color_format_property() to install this
+ * property. Possible values are "not applicable", "rgb", "ycbcr444",
+ * "ycbcr422", and "ycbcr420".
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -2205,6 +,52 @@ void drm_connector_set_active_bpc_property(struct 
drm_connector *connector, int
 }
 EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
 
+/**
+ * drm_connector_attach_active_color_format_property - attach "active color 
format" property
+ * @connector: connector to attach active color format property on.
+ *
+ * This is used to check the applied color format on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_format_property(struct drm_connector 
*connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   if (!connector->active_color_format_property) {
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, 
"active color format",
+   
drm_active_color_format_enum_list,
+   
ARRAY_SIZE(drm_active_color_format_enum_list));
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_color_format_property = prop;
+   }
+
+   drm_object_attach_property(>base, prop, 0);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_format_property);
+
+/**
+ * drm_connector_set_active_color_format_property - sets the active color 
format property for a
+ * connector
+ * @connector: drm connector
+ * @active_color_format: color format for the connector currently active "on 
the cable"
+ *
+ * Should be used by atomic drivers to update the active color format over a 
connector.
+ */
+void drm_connector_set_active_color_format_property(struct drm_connector 
*connector,
+   u32 active_color_format)
+{
+   drm_object_property_set_value(>base, 
connector->active_color_format_property,
+ active_color_format);
+}
+EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach 
"HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index eee86de62a5f..8a5197f14e87 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1386,6 +1386,12 @@ struct drm_connector {
 */
   

[Intel-gfx] [PATCH v5 05/17] drm/i915/display: Add handling for new "active bpc" property

2021-06-30 Thread Werner Sembach
This commit implements the "active bpc" drm property for the Intel GPU
driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 19 +++
 drivers/gpu/drm/i915/display/intel_dp.c  |  7 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c|  4 +++-
 4 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 6be1b31af07b..1b63d1404d06 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10839,6 +10839,9 @@ static int intel_atomic_commit(struct drm_device *dev,
 {
struct intel_atomic_state *state = to_intel_atomic_state(_state);
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_connector *connector;
+   struct drm_connector_state *new_conn_state;
+   int i;
int ret = 0;
 
state->wakeref = intel_runtime_pm_get(_priv->runtime_pm);
@@ -10907,6 +10910,22 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
 
+   /* Extract information from crtc to communicate it to userspace as 
connector properties */
+   for_each_new_connector_in_state(>base, connector, 
new_conn_state, i) {
+   struct intel_crtc *crtc = to_intel_crtc(new_conn_state->crtc);
+
+   if (crtc) {
+   struct intel_crtc_state *new_crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
+
+   drm_connector_set_active_bpc_property(connector,
+   new_crtc_state->dsc.compression_enable ?
+   new_crtc_state->dsc.compressed_bpp / 3 :
+   new_crtc_state->pipe_bpp / 3);
+   } else
+   drm_connector_set_active_bpc_property(connector, 0);
+   }
+
drm_atomic_state_get(>base);
INIT_WORK(>base.commit_work, intel_atomic_commit_work);
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6cc03b9e4321..815bc313b954 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4688,10 +4688,13 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
intel_attach_force_audio_property(connector);
 
intel_attach_broadcast_rgb_property(connector);
-   if (HAS_GMCH(dev_priv))
+   if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
-   else if (DISPLAY_VER(dev_priv) >= 5)
+   drm_connector_attach_active_bpc_property(connector, 6, 10);
+   } else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_bpc_property(connector, 6, 12);
+   }
 
/* Register HDMI colorspace for case of lspcon */
if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index b170e272bdee..16bfc59570a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -851,6 +851,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->max_bpc_property)
drm_connector_attach_max_bpc_property(connector, 6, 12);
 
+   connector->active_bpc_property =
+   intel_dp->attached_connector->base.active_bpc_property;
+   if (connector->active_bpc_property)
+   drm_connector_attach_active_bpc_property(connector, 6, 12);
+
return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 7e51c98c475e..9160e21ac9d6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2513,8 +2513,10 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
if (DISPLAY_VER(dev_priv) >= 10)
drm_connector_attach_hdr_output_metadata_property(connector);
 
-   if (!HAS_GMCH(dev_priv))
+   if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
+   drm_connector_attach_active_bpc_property(connector, 8, 12);
+   }
 }
 
 /*
-- 
2.25.1

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


[Intel-gfx] [PATCH v5 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-30 Thread Werner Sembach
Add a new general drm property "active bpc" which can be used by graphic
drivers to report the applied bit depth per pixel color 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 
---
 drivers/gpu/drm/drm_connector.c | 53 +
 include/drm/drm_connector.h |  8 +
 2 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..6461d00e8e49 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1197,6 +1197,15 @@ 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. This means after display stream compression and dithering
+ * done by the GPU. 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. A value of 0 means "not applicable".
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -2152,6 +2161,50 @@ 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;
+
+   if (!connector->active_bpc_property) {
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
"active bpc",
+min, max);
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_bpc_property = prop;
+   }
+
+   drm_object_attach_property(>base, prop, 0);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
+
+/**
+ * drm_connector_set_active_bpc_property - sets the active bits per color 
property for a connector
+ * @connector: drm connector
+ * @active_bpc: bits per color for the connector currently active "on the 
cable"
+ *
+ * Should be used by atomic drivers to update the active bits per color over a 
connector.
+ */
+void drm_connector_set_active_bpc_property(struct drm_connector *connector, 
int active_bpc)
+{
+   drm_object_property_set_value(>base, 
connector->active_bpc_property, active_bpc);
+}
+EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach 
"HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 714d1a01c065..eee86de62a5f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1380,6 +1380,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)
@@ -1702,6 +1708,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);
+void drm_connector_set_active_bpc_property(struct drm_connector *connector, 
int active_bpc);
 
 /**
  * struct drm_tile_group - Tile group met

[Intel-gfx] [PATCH v5 01/17] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check

2021-06-30 Thread Werner Sembach
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.

Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports drm_mode_is_420_only() even on a non HDMI connection.

This patch also moves both checks in the same if-case. This  eliminates an
extra else-if-case.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 10f878910e55..e081dd3ffb5f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5348,10 +5348,7 @@ static void fill_stream_properties_from_drm_display_mode(
timing_out->v_border_bottom = 0;
/* TODO: un-hardcode */
if (drm_mode_is_420_only(info, mode_in)
-   && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
-   timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
-   else if (drm_mode_is_420_also(info, mode_in)
-   && aconnector->force_yuv420_output)
+   || (drm_mode_is_420_also(info, mode_in) && 
aconnector->force_yuv420_output))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
else if ((connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
&& stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
-- 
2.25.1

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


[Intel-gfx] [PATCH v5 07/17] drm/amd/display: Add handling for new "active color format" property

2021-06-30 Thread Werner Sembach
This commit implements the "active color format" drm property for the AMD
GPU driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +--
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +++
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index d984de82ae63..098f3d53e681 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6710,6 +6710,24 @@ static int convert_dc_color_depth_into_bpc (enum 
dc_color_depth display_color_de
return 0;
 }
 
+static int convert_dc_pixel_encoding_into_drm_color_format(
+   enum dc_pixel_encoding display_pixel_encoding)
+{
+   switch (display_pixel_encoding) {
+   case PIXEL_ENCODING_RGB:
+   return DRM_COLOR_FORMAT_RGB444;
+   case PIXEL_ENCODING_YCBCR422:
+   return DRM_COLOR_FORMAT_YCRCB422;
+   case PIXEL_ENCODING_YCBCR444:
+   return DRM_COLOR_FORMAT_YCRCB444;
+   case PIXEL_ENCODING_YCBCR420:
+   return DRM_COLOR_FORMAT_YCRCB420;
+   default:
+   break;
+   }
+   return 0;
+}
+
 static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
  struct drm_crtc_state *crtc_state,
  struct drm_connector_state 
*conn_state)
@@ -7711,6 +7729,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   
drm_connector_attach_active_color_format_property(>base);
}
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
@@ -9090,14 +9109,20 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
stream = dm_new_crtc_state->stream;
 
-   if (stream)
+   if (stream) {
drm_connector_set_active_bpc_property(connector,
stream->timing.flags.DSC ?

stream->timing.dsc_cfg.bits_per_pixel / 16 / 3 :
convert_dc_color_depth_into_bpc(

stream->timing.display_color_depth));
-   } else
+   
drm_connector_set_active_color_format_property(connector,
+   
convert_dc_pixel_encoding_into_drm_color_format(
+   
dm_new_crtc_state->stream->timing.pixel_encoding));
+   }
+   } else {
drm_connector_set_active_bpc_property(connector, 0);
+   
drm_connector_set_active_color_format_property(connector, 0);
+   }
}
 
/* Count number of newly disabled CRTCs for dropping PM refs later. */
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 0cf38743ec47..13151d13aa73 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -413,6 +413,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(>base, 8, 
16);
 
+   connector->active_color_format_property = 
master->base.active_color_format_property;
+   if (connector->active_color_format_property)
+   
drm_connector_attach_active_color_format_property(>base);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1

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


[Intel-gfx] [PATCH v5 00/17] New uAPI drm properties for color management

2021-06-30 Thread Werner Sembach
Implementation of https://lkml.org/lkml/2021/5/12/764 now feature complete
albeit not fully tested.

I have now corrected the DSC behavior, but still no wait to test it.

Exact dithering behavior remains a mistery so in case dithering is active it's
not 100% clear what "active bpc" means, or where the "max bpc" limit is applied.

I have no DP MST splitter at hand. I tried my best to not break anything,
but if one who has one could test it would be very helpful.

Things on my TODO list:
- add "min bpc" property
- rewrite "preferred color format" to "force color format"
- make "Broadcast RGB" only affect RGB on AMD too
- remove unreachable enums of "active/preferred/force color format"


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


[Intel-gfx] [PATCH v5 02/17] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc

2021-06-30 Thread Werner Sembach
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to
an integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11
missing.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e081dd3ffb5f..f4abb5f215d1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6700,6 +6700,10 @@ static int convert_dc_color_depth_into_bpc (enum 
dc_color_depth display_color_de
return 14;
case COLOR_DEPTH_161616:
return 16;
+   case COLOR_DEPTH_999:
+   return 9;
+   case COLOR_DEPTH_11:
+   return 11;
default:
break;
}
-- 
2.25.1

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


Re: [Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-30 Thread Werner Sembach



Am 30.06.21 um 10:21 schrieb Pekka Paalanen:

On Tue, 29 Jun 2021 13:02:05 +0200
Werner Sembach  wrote:


Am 28.06.21 um 19:03 schrieb Werner Sembach:

Am 18.06.21 um 11:11 schrieb Werner Sembach:

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 
---
  drivers/gpu/drm/drm_connector.c | 51 +
  include/drm/drm_connector.h |  8 ++
  2 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..943f6b61053b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1197,6 +1197,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.
+ *

Regarding "on the cable" and dithering: As far as I can tell, what the 
dithering option does, is setting a hardware
register here:

- 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534

- 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571

So dithering seems to be calculated by fixed purpose hardware/firmware outside 
of the driver?

The Intel driver does not seem to set a target bpc/bpp for this hardware so I 
guess it defaults to 6 or 8 bpc?

Never mind it does. This switch-case does affect the dithering output:
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537

Hi,

I obviously do not know the intel driver or hardware at all, but
to me that just looks like translating from bits per pixel to bits per
channel in RGB mapping?
No, if i understand the documentation correctly: Writing bit depth here 
with dithering enabled sets the dithering target bpc.



As found in this documentation p.548:
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf

So max bpc and active bpc are affecting/affected by the bpc after dithering.

By definition, if the cable carries N bpc, then dithering does not
change that. The cable still carries N bpc, but due to spatial or
temporal dithering, the *observed* color resolution may or may not be
higher than the cable bpc.
Yes, and max bpc and active bpc tell the cable bpc ist not the 
*observed* bpc.


Of course, if the cable bpc is 8, and dithering targets 6 bpc, then 2
LSB on the cable are always zero, right?
I would assume that in this case only 6 bpc are actually send? Isn't the 
whole thing of dithering that you can't send, for example, 8 bpc?


Maybe one would want to do that if the monitor has a 6 bit panel and it
simply ignored the 2 LSB, and the cable cannot go down to 6 bpc.


Is there dithering actually doing this? aka is my assumption above wrong?

AMD code that confused me before, is hinting that you might be right: 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L826


there is a set_clamp depth and a separate DCP_SPATIAL_DITHER_DEPTH_30BPP



So, what does "max bpc" mean right now?

It seems like dither on/off is insufficient information, one would also
need to control the dithering target bpc. I suppose the driver has a
policy on how it chooses the target bpc, but what is that policy? Is
the dither target bpc the cable bpc or the sink bpc?

Needless to say, I'm quite confused.


... We need someone who knows what dithering on intel and amd gpu 
actually means.


But I don't want this to become a blocker for this patchset, because if 
there is no dithering, which seems to be the norm, the active bpc 
property is already really usefull as it is. So add a note to the docs 
that the value might be invalid when dithering is active for now?





Thanks,
pq


Similar things happen on amd. Here the output dither depth seems to be written 
to a fixed value however:

- 
https://elixi

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-06-30 Thread Werner Sembach

Am 30.06.21 um 10:41 schrieb Pekka Paalanen:


On Tue, 29 Jun 2021 13:39:18 +0200
Werner Sembach  wrote:


Am 29.06.21 um 13:17 schrieb Pekka Paalanen:

On Tue, 29 Jun 2021 08:12:54 +
Simon Ser  wrote:
  

On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen  
wrote:
  

yes, I think this makes sense, even if it is a property that one can't
tell for sure what it does before hand.

Using a pair of properties, preference and active, to ask for something
and then check what actually worked is good for reducing the
combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
test different KMS configurations. Userspace has a better chance of
finding a configuration that is possible.

OTOH, this has the problem than in UI one cannot tell the user in
advance which options are truly possible. Given that KMS properties are
rarely completely independent, and in this case known to depend on
several other KMS properties, I think it is good enough to know after
the fact.

If a driver does not use what userspace prefers, there is no way to
understand why, or what else to change to make it happen. That problem
exists anyway, because TEST_ONLY commits do not give useful feedback
but only a yes/no.

By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
property at a time), user-space can discover which property makes the atomic
commit fail.

That works if the properties are independent of each other. Color
range, color format, bpc and more may all be interconnected,
allowing only certain combinations to work.

If all these properties have "auto" setting too, then it would be
possible to probe each property individually, but that still does not
tell which combinations are valid.

If you probe towards a certain configuration by setting the properties
one by one, then depending on the order you pick the properties, you
may come to a different conclusion on which property breaks the
configuration.

My mind crossed another point that must be considered: When plugin in
a Monitor a list of possible Resolutions+Framerate combinations is
created for xrandr and other userspace (I guess by atomic checks? but
I don't know).

Hi,

I would not think so, but I hope to be corrected if I'm wrong.

My belief is that the driver collects a list of modes from EDID, some
standard modes, and maybe some other hardcoded modes, and then
validates each entry against all the known limitations like vertical
and horizontal frequency limits, discarding modes that do not fit.

Not all limitations are known during that phase, which is why KMS
property "link-status" exists. When userspace actually programs a mode
(not a TEST_ONLY commit), the link training may fail. The kernel prunes
the mode from the list and sets the link status property to signal
failure, and sends a hotplug uevent. Userspace needs to re-check the
mode list and try again.

That is a generic escape hatch for when TEST_ONLY commit succeeds, but
in reality the hardware cannot do it, you just cannot know until you
actually try for real. It causes end user visible flicker if it happens
on an already running connector, but since it usually happens when
turning a connector on to begin with, there is no flicker to be seen,
just a small delay in finding a mode that works.


During this drm
properties are already considered, which is no problem atm because as
far as i can tell there is currently no drm property that would make
a certain Resolutions+Framerate combination unreachable that would be
possible with everything on default.

I would not expect KMS properties to be considered at all. It would
reject modes that are actually possible if the some KMS properties were
changed. So at least going forward, current KMS property values cannot
factor in.


At least the debugfs variable "force_yuv420_output" did change the 
available modes here: 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165 
before my patch 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf


Forcing a color format via a DRM property in this function would 
reintroduce the problem.


And I think i915 driver works similar in this regard.




However for example forcing YCbCr420 encoding would limit the
available resolutions (my screen for example only supports YCbCr420
on 4k@60 and @50Hz and on no other resolution or frequency (native is
2560x1440@144Hz).

So would a "force color format" that does not get resetted on
repluging/reenabling a monitor break the output, for example, of an
not updated xrandr, unaware of this new property?

Yes, not because the mode list would be missing the mode, but because
actually setting the mode would fail.
Well, like described above, I think the mode would actually be missing, 
which is also an unexpected behavior from a user perspective.


RandR in particular is problematic, because 

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-06-29 Thread Werner Sembach


Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> On Tue, 29 Jun 2021 08:12:54 +
> Simon Ser  wrote:
>
>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen  
>> wrote:
>>
>>> yes, I think this makes sense, even if it is a property that one can't
>>> tell for sure what it does before hand.
>>>
>>> Using a pair of properties, preference and active, to ask for something
>>> and then check what actually worked is good for reducing the
>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>> test different KMS configurations. Userspace has a better chance of
>>> finding a configuration that is possible.
>>>
>>> OTOH, this has the problem than in UI one cannot tell the user in
>>> advance which options are truly possible. Given that KMS properties are
>>> rarely completely independent, and in this case known to depend on
>>> several other KMS properties, I think it is good enough to know after
>>> the fact.
>>>
>>> If a driver does not use what userspace prefers, there is no way to
>>> understand why, or what else to change to make it happen. That problem
>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>> but only a yes/no.  
>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
>> property at a time), user-space can discover which property makes the atomic
>> commit fail.
> That works if the properties are independent of each other. Color
> range, color format, bpc and more may all be interconnected,
> allowing only certain combinations to work.
>
> If all these properties have "auto" setting too, then it would be
> possible to probe each property individually, but that still does not
> tell which combinations are valid.
>
> If you probe towards a certain configuration by setting the properties
> one by one, then depending on the order you pick the properties, you
> may come to a different conclusion on which property breaks the
> configuration.

My mind crossed another point that must be considered: When plugin in a Monitor 
a list of possible Resolutions+Framerate
combinations is created for xrandr and other userspace (I guess by atomic 
checks? but I don't know). During this drm
properties are already considered, which is no problem atm because as far as i 
can tell there is currently no drm
property that would make a certain Resolutions+Framerate combination 
unreachable that would be possible with everything
on default.

However for example forcing YCbCr420 encoding would limit the available 
resolutions (my screen for example only supports
YCbCr420 on 4k@60 and @50Hz and on no other resolution or frequency (native is 
2560x1440@144Hz).

So would a "force color format" that does not get resetted on 
repluging/reenabling a monitor break the output, for
example, of an not updated xrandr, unaware of this new property?

>> I'm not a fan of this "preference" property approach. The only way to find 
>> out
>> whether it's possible to change the color format is to perform a user-visible
>> change (with a regular atomic commit) and check whether it worked
>> after-the-fact. This is unlike all other existing KMS properties.
> I agree. FWIW, "max bpc" exists already.
>
>> I'd much rather see a more general approach to fix this combinatorial 
>> explosion
>> than to add special-cases like this.
> What would you suggest?
>
> Maybe all properties should have an "auto" value in addition to the
> explicit no-negotiation values where at all possible?
>
> That might help probing each property individually with TEST_ONLY
> commits, but it says nothing about combinations.
>
> A feedback list perhaps? TEST_ONLY commit somehow returning a list of
> property/value tuples indicating what value the "auto" valued
> properties actually get?
>
> What should a kernel driver optimize for when determining "auto" values?
>
>
> Thanks,
> pq
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-06-29 Thread Werner Sembach

Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> On Tue, 29 Jun 2021 08:12:54 +
> Simon Ser  wrote:
>
>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen  
>> wrote:
>>
>>> yes, I think this makes sense, even if it is a property that one can't
>>> tell for sure what it does before hand.
>>>
>>> Using a pair of properties, preference and active, to ask for something
>>> and then check what actually worked is good for reducing the
>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>> test different KMS configurations. Userspace has a better chance of
>>> finding a configuration that is possible.
>>>
>>> OTOH, this has the problem than in UI one cannot tell the user in
>>> advance which options are truly possible. Given that KMS properties are
>>> rarely completely independent, and in this case known to depend on
>>> several other KMS properties, I think it is good enough to know after
>>> the fact.
>>>
>>> If a driver does not use what userspace prefers, there is no way to
>>> understand why, or what else to change to make it happen. That problem
>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>> but only a yes/no.  
>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
>> property at a time), user-space can discover which property makes the atomic
>> commit fail.
> That works if the properties are independent of each other. Color
> range, color format, bpc and more may all be interconnected,
> allowing only certain combinations to work.
>
> If all these properties have "auto" setting too, then it would be
> possible to probe each property individually, but that still does not
> tell which combinations are valid.
>
> If you probe towards a certain configuration by setting the properties
> one by one, then depending on the order you pick the properties, you
> may come to a different conclusion on which property breaks the
> configuration.

My mind crossed another point that must be considered: When plugin in a Monitor 
a list of possible Resolutions+Framerate
combinations is created for xrandr and other userspace (I guess by atomic 
checks? but I don't know). During this drm
properties are already considered, which is no problem atm because as far as i 
can tell there is currently no drm
property that would make a certain Resolutions+Framerate combination 
unreachable that would be possible with everything
on default.

However for example forcing YCbCr420 encoding would limit the available 
resolutions (my screen for example only supports
YCbCr420 on 4k@60 and @50Hz and on no other resolution or frequency (native is 
2560x1440@144Hz).

So would a "force color format" that does not get resetted on 
repluging/reenabling a monitor break the output, for
example, of an not updated xrandr, unaware of this new property?

>
>> I'm not a fan of this "preference" property approach. The only way to find 
>> out
>> whether it's possible to change the color format is to perform a user-visible
>> change (with a regular atomic commit) and check whether it worked
>> after-the-fact. This is unlike all other existing KMS properties.
> I agree. FWIW, "max bpc" exists already.
>
>> I'd much rather see a more general approach to fix this combinatorial 
>> explosion
>> than to add special-cases like this.
> What would you suggest?
>
> Maybe all properties should have an "auto" value in addition to the
> explicit no-negotiation values where at all possible?
>
> That might help probing each property individually with TEST_ONLY
> commits, but it says nothing about combinations.
>
> A feedback list perhaps? TEST_ONLY commit somehow returning a list of
> property/value tuples indicating what value the "auto" valued
> properties actually get?
>
> What should a kernel driver optimize for when determining "auto" values?
>
>
> Thanks,
> pq
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-29 Thread Werner Sembach
Am 28.06.21 um 19:03 schrieb Werner Sembach:
> Am 18.06.21 um 11:11 schrieb Werner Sembach:
>> 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 
>> ---
>>  drivers/gpu/drm/drm_connector.c | 51 +
>>  include/drm/drm_connector.h |  8 ++
>>  2 files changed, 59 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c 
>> b/drivers/gpu/drm/drm_connector.c
>> index da39e7ff6965..943f6b61053b 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1197,6 +1197,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.
>> + *
> Regarding "on the cable" and dithering: As far as I can tell, what the 
> dithering option does, is setting a hardware
> register here:
>
> - 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
>
> - 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
>
> So dithering seems to be calculated by fixed purpose hardware/firmware 
> outside of the driver?
>
> The Intel driver does not seem to set a target bpc/bpp for this hardware so I 
> guess it defaults to 6 or 8 bpc?

Never mind it does. This switch-case does affect the dithering output:
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537

As found in this documentation p.548:
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf

So max bpc and active bpc are affecting/affected by the bpc after dithering.

>
> Similar things happen on amd. Here the output dither depth seems to be 
> written to a fixed value however:
>
> - 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L828
>
> - 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L769
>
> Does anyone know about a resource where I can read up on the used registers 
> and what this hardware actually does?
Searching now for a similar register reference for AMD GPUs.
>
> My proposal for now: "max bpc" affects what happens before dither, so I would 
> keep "active bpc" the same and add another
> drm property "dither active: true/false". No additional property to control 
> dither, as amdgpu does have one already
> (which isn't always active?) and Intel driver does only seem prepared for 
> dithering at 6bpc (albeit I don't know why to
> dither at 6bpc and what depth to dither to?).
>
>>   * Connectors also have one standardized atomic property:
>>   *
>>   * CRTC_ID:
>> @@ -2152,6 +2160,49 @@ 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(s

Re: [Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-28 Thread Werner Sembach
Am 18.06.21 um 11:11 schrieb Werner Sembach:
> 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 
> ---
>  drivers/gpu/drm/drm_connector.c | 51 +
>  include/drm/drm_connector.h |  8 ++
>  2 files changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index da39e7ff6965..943f6b61053b 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1197,6 +1197,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.
> + *

Regarding "on the cable" and dithering: As far as I can tell, what the 
dithering option does, is setting a hardware
register here:

- 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534

- 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571

So dithering seems to be calculated by fixed purpose hardware/firmware outside 
of the driver?

The Intel driver does not seem to set a target bpc/bpp for this hardware so I 
guess it defaults to 6 or 8 bpc?

Similar things happen on amd. Here the output dither depth seems to be written 
to a fixed value however:

- 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L828

- 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L769

Does anyone know about a resource where I can read up on the used registers and 
what this hardware actually does?

My proposal for now: "max bpc" affects what happens before dither, so I would 
keep "active bpc" the same and add another
drm property "dither active: true/false". No additional property to control 
dither, as amdgpu does have one already
(which isn't always active?) and Intel driver does only seem prepared for 
dithering at 6bpc (albeit I don't know why to
dither at 6bpc and what depth to dither to?).

>   * Connectors also have one standardized atomic property:
>   *
>   * CRTC_ID:
> @@ -2152,6 +2160,49 @@ 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;
> +
> + if (!connector->active_bpc_property) {
> + prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
> "active bpc",
> +  min, max);
> + if (!prop)
> + return -ENOMEM;
> +
> + connector->active_bpc_property = prop;
> + drm_object_attach_property(>base, prop, 0);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
> +
> +/**
> + * drm_connector_set_active_bpc_property - sets the active bits per color 
> property for a connector
> + * @connector: drm connector
> + * @active_bpc: bits per color for

Re: [Intel-gfx] [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context

2021-06-25 Thread Werner Sembach


Am 23.06.21 um 13:26 schrieb Pekka Paalanen:
> On Wed, 23 Jun 2021 12:10:14 +0200
> Werner Sembach  wrote:
>
>> Am 23.06.21 um 09:48 schrieb Pekka Paalanen:
>>> On Tue, 22 Jun 2021 11:57:53 +0200
>>> Werner Sembach  wrote:
>>>  
>>>> Am 22.06.21 um 09:25 schrieb Pekka Paalanen:  
>>>>> On Fri, 18 Jun 2021 11:11:14 +0200
>>>>> Werner Sembach  wrote:
>>>>>
>>>>>> Add "Broadcast RGB" to general drm context so that more drivers besides
>>>>>> i915 and gma500 can implement it without duplicating code.
>>>>>>
>>>>>> Userspace can use this property to tell the graphic driver to use full or
>>>>>> limited color range for a given connector, overwriting the default
>>>>>> behaviour/automatic detection.
>>>>>>
>>>>>> Possible options are:
>>>>>> - Automatic (default/current behaviour)
>>>>>> - Full
>>>>>> - Limited 16:235
>>>>>>
>>>>>> In theory the driver should be able to automatically detect the monitors
>>>>>> capabilities, but because of flawed standard implementations in Monitors,
>>>>>> this might fail. In this case a manual overwrite is required to not have
>>>>>> washed out colors or lose details in very dark or bright scenes.
>>>>>>
>>>>>> Signed-off-by: Werner Sembach 
>>>>>> ---
>>>>>>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
>>>>>>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
>>>>>>  drivers/gpu/drm/drm_connector.c | 43 +
>>>>>>  include/drm/drm_connector.h | 16 +++
>>>>>>  4 files changed, 67 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>>>>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>> index 90d62f305257..0c89d32efbd0 100644
>>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device 
>>>>>> *dev,
>>>>>>  if (old_connector_state->preferred_color_format 
>>>>>> !=
>>>>>>  new_connector_state->preferred_color_format)
>>>>>>  new_crtc_state->connectors_changed = 
>>>>>> true;
>>>>>> +
>>>>>> +if (old_connector_state->preferred_color_range 
>>>>>> !=
>>>>>> +new_connector_state->preferred_color_range)
>>>>>> +new_crtc_state->connectors_changed = 
>>>>>> true;
>>>>>>  }
>>>>>>  
>>>>>>  if (funcs->atomic_check)
>>>>>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
>>>>>> b/drivers/gpu/drm/drm_atomic_uapi.c
>>>>>> index c536f5e22016..c589bb1a8163 100644
>>>>>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>>>>>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>>>>>> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct 
>>>>>> drm_connector *connector,
>>>>>>  state->max_requested_bpc = val;
>>>>>>  } else if (property == 
>>>>>> connector->preferred_color_format_property) {
>>>>>>  state->preferred_color_format = val;
>>>>>> +} else if (property == 
>>>>>> connector->preferred_color_range_property) {
>>>>>> +state->preferred_color_range = val;
>>>>>>  } else if (connector->funcs->atomic_set_property) {
>>>>>>  return connector->funcs->atomic_set_property(connector,
>>>>>>  state, property, val);
>>>>>> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct 
>>>>>> drm_connector *connector,
>>>>>>  *val = state->max_requested_bpc;
>>>>>>  } else if (property == 
>>>>>> c

Re: [Intel-gfx] [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

2021-06-23 Thread Werner Sembach
Am 23.06.21 um 13:14 schrieb Pekka Paalanen:
> On Wed, 23 Jun 2021 12:17:40 +0200
> Werner Sembach  wrote:
>
>> Am 23.06.21 um 09:32 schrieb Pekka Paalanen:
>>> On Tue, 22 Jun 2021 11:48:52 +
>>> Simon Ser  wrote:
>>>  
>>>> On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach 
>>>>  wrote:
>>>>  
>>>>> Unknown is when no monitor is connected or is when the
>>>>> connector/monitor is disabled.
>>>> I think the other connector props (link-status, non-desktop, etc) don't
>>>> have a special "unset" value, and instead the value is set to a random
>>>> enum entry. User-space should ignore the prop on these disconnected
>>>> connectors anyways.  
>>> That sounds fine to me.  
>> Currently the only case for "not applicable" is when the monitor is
>> disconnected, but sicne the properties are so interdependent, there
>> might be a case in the future where e.g. a color format that has no
>> differentiation between full and limited arises. When there is no
>> special unset/not applicable option, the userspace has to know
>> exactly when an option is valid or not, possible requiring additional
>> logic.
>>
>> Setting a "not applicable" value allows userspace to be more dumb,
>> without much hassle on the kernelspace side.
> That's a good point too. So "not applicable" would be a value, but
> "unknown" would not be.
Ok, I have already renamed the "unknown" option to "not applicable" in my next 
revision (not yet posted to the mailing
list).
>
>
> Thanks,
> pq
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

2021-06-23 Thread Werner Sembach


Am 23.06.21 um 09:32 schrieb Pekka Paalanen:
> On Tue, 22 Jun 2021 11:48:52 +
> Simon Ser  wrote:
>
>> On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach 
>>  wrote:
>>
>>> Unknown is when no monitor is connected or is when the
>>> connector/monitor is disabled.  
>> I think the other connector props (link-status, non-desktop, etc) don't
>> have a special "unset" value, and instead the value is set to a random
>> enum entry. User-space should ignore the prop on these disconnected
>> connectors anyways.
> That sounds fine to me.

Currently the only case for "not applicable" is when the monitor is 
disconnected, but sicne the properties are so
interdependent, there might be a case in the future where e.g. a color format 
that has no differentiation between full
and limited arises. When there is no special unset/not applicable option, the 
userspace has to know exactly when an
option is valid or not, possible requiring additional logic.

Setting a "not applicable" value allows userspace to be more dumb, without much 
hassle on the kernelspace side.

>
>
> Thanks,
> pq
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context

2021-06-23 Thread Werner Sembach
Am 23.06.21 um 09:48 schrieb Pekka Paalanen:
> On Tue, 22 Jun 2021 11:57:53 +0200
> Werner Sembach  wrote:
>
>> Am 22.06.21 um 09:25 schrieb Pekka Paalanen:
>>> On Fri, 18 Jun 2021 11:11:14 +0200
>>> Werner Sembach  wrote:
>>>  
>>>> Add "Broadcast RGB" to general drm context so that more drivers besides
>>>> i915 and gma500 can implement it without duplicating code.
>>>>
>>>> Userspace can use this property to tell the graphic driver to use full or
>>>> limited color range for a given connector, overwriting the default
>>>> behaviour/automatic detection.
>>>>
>>>> Possible options are:
>>>> - Automatic (default/current behaviour)
>>>> - Full
>>>> - Limited 16:235
>>>>
>>>> In theory the driver should be able to automatically detect the monitors
>>>> capabilities, but because of flawed standard implementations in Monitors,
>>>> this might fail. In this case a manual overwrite is required to not have
>>>> washed out colors or lose details in very dark or bright scenes.
>>>>
>>>> Signed-off-by: Werner Sembach 
>>>> ---
>>>>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
>>>>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
>>>>  drivers/gpu/drm/drm_connector.c | 43 +
>>>>  include/drm/drm_connector.h | 16 +++
>>>>  4 files changed, 67 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>>> index 90d62f305257..0c89d32efbd0 100644
>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>>> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device 
>>>> *dev,
>>>>if (old_connector_state->preferred_color_format !=
>>>>new_connector_state->preferred_color_format)
>>>>new_crtc_state->connectors_changed = true;
>>>> +
>>>> +  if (old_connector_state->preferred_color_range !=
>>>> +  new_connector_state->preferred_color_range)
>>>> +  new_crtc_state->connectors_changed = true;
>>>>}
>>>>  
>>>>if (funcs->atomic_check)
>>>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
>>>> b/drivers/gpu/drm/drm_atomic_uapi.c
>>>> index c536f5e22016..c589bb1a8163 100644
>>>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>>>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>>>> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct 
>>>> drm_connector *connector,
>>>>state->max_requested_bpc = val;
>>>>} else if (property == connector->preferred_color_format_property) {
>>>>state->preferred_color_format = val;
>>>> +  } else if (property == connector->preferred_color_range_property) {
>>>> +  state->preferred_color_range = val;
>>>>} else if (connector->funcs->atomic_set_property) {
>>>>return connector->funcs->atomic_set_property(connector,
>>>>state, property, val);
>>>> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector 
>>>> *connector,
>>>>*val = state->max_requested_bpc;
>>>>} else if (property == connector->preferred_color_format_property) {
>>>>*val = state->preferred_color_format;
>>>> +  } else if (property == connector->preferred_color_range_property) {
>>>> +  *val = state->preferred_color_range;
>>>>} 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 aea03dd02e33..9bc596638613 100644
>>>> --- a/drivers/gpu/drm/drm_connector.c
>>>> +++ b/drivers/gpu/drm/drm_connector.c
>>>> @@ -905,6 +905,12 @@ static const struct drm_prop_enum_list 
>>>> drm_active_color_format_enum_list[] = {
>>>>{ DRM_COLOR_FORMAT_YC

Re: [Intel-gfx] [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property

2021-06-23 Thread Werner Sembach
Am 23.06.21 um 10:01 schrieb Pekka Paalanen:
> On Tue, 22 Jun 2021 11:28:57 +0200
> Werner Sembach  wrote:
>
>> Am 22.06.21 um 09:29 schrieb Pekka Paalanen:
>>> On Fri, 18 Jun 2021 11:11:16 +0200
>>> Werner Sembach  wrote:
>>>  
>>>> This commit implements the "Broadcast RGB" drm property for the AMD GPU
>>>> driver.
>>>>
>>>> Signed-off-by: Werner Sembach 
>>>> ---
>>>>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
>>>>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 
>>>>  2 files changed, 21 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
>>>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>>> index 9ffd2f9d3d75..c5dbf948a47a 100644
>>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>>> @@ -5252,7 +5252,8 @@ get_aspect_ratio(const struct drm_display_mode 
>>>> *mode_in)
>>>>  }
>>>>  
>>>>  static enum dc_color_space
>>>> -get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
>>>> +get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
>>>> + enum drm_mode_color_range preferred_color_range)
>>>>  {
>>>>enum dc_color_space color_space = COLOR_SPACE_SRGB;
>>>>  
>>>> @@ -5267,13 +5268,17 @@ get_output_color_space(const struct dc_crtc_timing 
>>>> *dc_crtc_timing)
>>>> * respectively
>>>> */
>>>>if (dc_crtc_timing->pix_clk_100hz > 270300) {
>>>> -  if (dc_crtc_timing->flags.Y_ONLY)
>>>> +  if (dc_crtc_timing->flags.Y_ONLY
>>>> +  || preferred_color_range ==
>>>> +  
>>>> DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>>>>color_space =
>>>>COLOR_SPACE_YCBCR709_LIMITED;
>>>>else
>>>>color_space = COLOR_SPACE_YCBCR709;  
>>> Hi,
>>>
>>> does this mean that amdgpu would be using a property named "Broadcast
>>> RGB" to control the range of YCbCr too?  
>> Yes, because I avoided creating a new property, but I'm not really happy 
>> with it either.
>>
>> Possibility 1: Use "Broadcast RGB" for Y'CbCr too and clarify in 
>> documentation
>>     - still confusing name
>>     - limited does not mean something a little bit different for Y'CbCr and 
>> not strictly 16-235:
>> https://www.kernel.org/doc/html/v5.12/userspace-api/media/v4l/colorspaces-defs.html#c.V4L.v4l2_quantization
>>  , but name
>> of option is given by preexisting property
>>
>> Possibility 2: Deprecate "Broadcast RGB" and a a more neutral sounding 
>> "preferred color range", with the more neutral
>> sounding "limited" option instead of "Limited 16:235"
>>     - What's the relation between the 2? pq mentioned on the amdgpu
>> gitlab that there is a posibility for userspace to have only the new
>> or the old one shown
> It's just an idea that we could decide to expose only one or the other
> property. It would need to be engineered in code, go through the UAPI
> validation with userspace etc. I'm not aware of this being done before
> exactly like this, but DRM client caps exist.
>
>>     - Alternatively ignore "Broadcast RGB" when "preferred color range" is 
>> set and have them coexist?
> Determining "is set" means we would need "unset" value for "preferred
> color range". But there is no notion of who set it. If some KMS client
> decides to set it, then it will likely remain set, even if you next
> start another KMS client who does not use this property - it would just
> confuse users when "Broadcast RGB" silently stopped working while it
> still exists.
Unset would be the "auto" option. But i think this problem exists already e.g. 
a KMS client is unaware of the new
"preferred color format" property and sets "Broadcast RGB" on intel which does 
nothing in the case of Y'CbCr.

Since the properties affecting each other, having only one not at default, 
potentially breaks KMS clients unaware of
them regardless.
>
> So I don't think 

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

2021-06-22 Thread Werner Sembach

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

Re: [Intel-gfx] [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context

2021-06-22 Thread Werner Sembach
Am 22.06.21 um 09:25 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:14 +0200
> Werner Sembach  wrote:
>
>> Add "Broadcast RGB" to general drm context so that more drivers besides
>> i915 and gma500 can implement it without duplicating code.
>>
>> Userspace can use this property to tell the graphic driver to use full or
>> limited color range for a given connector, overwriting the default
>> behaviour/automatic detection.
>>
>> Possible options are:
>> - Automatic (default/current behaviour)
>> - Full
>> - Limited 16:235
>>
>> In theory the driver should be able to automatically detect the monitors
>> capabilities, but because of flawed standard implementations in Monitors,
>> this might fail. In this case a manual overwrite is required to not have
>> washed out colors or lose details in very dark or bright scenes.
>>
>> Signed-off-by: Werner Sembach 
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
>>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
>>  drivers/gpu/drm/drm_connector.c | 43 +
>>  include/drm/drm_connector.h | 16 +++
>>  4 files changed, 67 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 90d62f305257..0c89d32efbd0 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>>  if (old_connector_state->preferred_color_format !=
>>  new_connector_state->preferred_color_format)
>>  new_crtc_state->connectors_changed = true;
>> +
>> +if (old_connector_state->preferred_color_range !=
>> +new_connector_state->preferred_color_range)
>> +new_crtc_state->connectors_changed = true;
>>  }
>>  
>>  if (funcs->atomic_check)
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index c536f5e22016..c589bb1a8163 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct 
>> drm_connector *connector,
>>  state->max_requested_bpc = val;
>>  } else if (property == connector->preferred_color_format_property) {
>>  state->preferred_color_format = val;
>> +} else if (property == connector->preferred_color_range_property) {
>> +state->preferred_color_range = val;
>>  } else if (connector->funcs->atomic_set_property) {
>>  return connector->funcs->atomic_set_property(connector,
>>  state, property, val);
>> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector 
>> *connector,
>>  *val = state->max_requested_bpc;
>>  } else if (property == connector->preferred_color_format_property) {
>>  *val = state->preferred_color_format;
>> +} else if (property == connector->preferred_color_range_property) {
>> +*val = state->preferred_color_range;
>>  } 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 aea03dd02e33..9bc596638613 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -905,6 +905,12 @@ static const struct drm_prop_enum_list 
>> drm_active_color_format_enum_list[] = {
>>  { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>>  };
>>  
>> +static const struct drm_prop_enum_list 
>> drm_preferred_color_range_enum_list[] = {
>> +{ DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
>> +{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>> +{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
> Hi,
>
> the same question here about these numbers as I asked on the "active
> color range" property.
>
>> +};
>> +
>>  static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = 
>> {
>>  { DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
>>  { DRM_

Re: [Intel-gfx] [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

2021-06-22 Thread Werner Sembach


Am 22.06.21 um 09:00 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:08 +0200
> Werner Sembach  wrote:
>
>> Add a new general drm property "active color range" which can be used by
>> graphic drivers to report the used color range back to userspace.
>>
>> There was no way to check which color range got actually used on a given
>> monitor. To surely predict this, one must know the exact capabilities of
>> the monitor and what the default behaviour of the used driver is. This
>> property helps eliminating the guessing at this point.
>>
>> In the future, automatic color calibration for screens might also depend on
>> this information being available.
>>
>> Signed-off-by: Werner Sembach 
>> ---
>>  drivers/gpu/drm/drm_connector.c | 59 +
>>  include/drm/drm_connector.h | 27 +++
>>  2 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c 
>> b/drivers/gpu/drm/drm_connector.c
>> index 684d7abdf0eb..818de58d972f 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -897,6 +897,12 @@ static const struct drm_prop_enum_list 
>> drm_active_color_format_enum_list[] = {
>>  { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>>  };
>>  
>> +static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = 
>> {
>> +{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
>> +{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>> +{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
> Doesn't "limited" mean different numbers on RGB vs. Y vs. CbCr? I have
> a vague recollection that at least one of them was different from the
> others.

Yes, seems like it does:
https://www.kernel.org/doc/html/v5.12/userspace-api/media/v4l/colorspaces-defs.html#c.V4L.v4l2_quantization

I carried the option names over from "Broadcast RGB", see my other e-mail for 
more details.

>
> Documenting DRM_MODE_COLOR_RANGE_UNSET as "unspecified/default" while
> the string for it is "Unknown" seems inconsistent to me. I would
> recommend to avoid the word "default" because "reset to defaults" might
> become a thing one day, and that probably is not the same default as
> here.
>
> Is there actually a case for "unknown"? How can it be not known? Or
> does it mean "not applicable"?

Unknown is when no monitor is connected or is when the connector/monitor is 
disabled.

It also is the initial value when the driver fails to correctly set the 
property. This shouldn't happen, but I'm
wondering if I should still introduce an _ERROR state instead for this case?

I will rename it, maybe "unset" to match the enum? "not applicable" also fits 
if either the error state is defined or
not necessary.

>
> Otherwise looks good to me.
>
>
> Thanks,
> pq
>
>
>> +};
>> +
>>  DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
>>   drm_dp_subconnector_enum_list)
>>  
>> @@ -1221,6 +1227,14 @@ static const struct drm_prop_enum_list 
>> dp_colorspaces[] = {
>>   *  drm_connector_attach_active_color_format_property() to install this
>>   *  property.
>>   *
>> + * active color range:
>> + *  This read-only property tells userspace the color range actually used by
>> + *  the hardware display engine on "the cable" on a connector. The chosen
>> + *  value depends on hardware capabilities of the monitor and the used color
>> + *  format. Drivers shall use
>> + *  drm_connector_attach_active_color_range_property() to install this
>> + *  property.
>> + *
>>   * Connectors also have one standardized atomic property:
>>   *
>>   * CRTC_ID:
>> @@ -2264,6 +2278,51 @@ void 
>> drm_connector_set_active_color_format_property(struct drm_connector *connec
>>  }
>>  EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
>>  
>> +/**
>> + * drm_connector_attach_active_color_range_property - attach "active color 
>> range" property
>> + * @connector: connector to attach active color range property on.
>> + *
>> + * This is used to check the applied color range on a connector.
>> + *
>> + * Returns:
>> + * Zero on success, negative errno on failure.
>> + */
>> +int drm_connector_attach_active_color_range_property(struct drm_connector 
>> *connector)
>> +{
>> +struct drm_device *dev = connector->dev;
>> +struct drm_property *prop

Re: [Intel-gfx] [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property

2021-06-22 Thread Werner Sembach
Am 22.06.21 um 09:29 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:16 +0200
> Werner Sembach  wrote:
>
>> This commit implements the "Broadcast RGB" drm property for the AMD GPU
>> driver.
>>
>> Signed-off-by: Werner Sembach 
>> ---
>>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
>>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 
>>  2 files changed, 21 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 9ffd2f9d3d75..c5dbf948a47a 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -5252,7 +5252,8 @@ get_aspect_ratio(const struct drm_display_mode 
>> *mode_in)
>>  }
>>  
>>  static enum dc_color_space
>> -get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
>> +get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
>> +   enum drm_mode_color_range preferred_color_range)
>>  {
>>  enum dc_color_space color_space = COLOR_SPACE_SRGB;
>>  
>> @@ -5267,13 +5268,17 @@ get_output_color_space(const struct dc_crtc_timing 
>> *dc_crtc_timing)
>>   * respectively
>>   */
>>  if (dc_crtc_timing->pix_clk_100hz > 270300) {
>> -if (dc_crtc_timing->flags.Y_ONLY)
>> +if (dc_crtc_timing->flags.Y_ONLY
>> +|| preferred_color_range ==
>> +
>> DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>>  color_space =
>>  COLOR_SPACE_YCBCR709_LIMITED;
>>  else
>>  color_space = COLOR_SPACE_YCBCR709;
> Hi,
>
> does this mean that amdgpu would be using a property named "Broadcast
> RGB" to control the range of YCbCr too?

Yes, because I avoided creating a new property, but I'm not really happy with 
it either.

Possibility 1: Use "Broadcast RGB" for Y'CbCr too and clarify in documentation
    - still confusing name
    - limited does not mean something a little bit different for Y'CbCr and not 
strictly 16-235:
https://www.kernel.org/doc/html/v5.12/userspace-api/media/v4l/colorspaces-defs.html#c.V4L.v4l2_quantization
 , but name
of option is given by preexisting property

Possibility 2: Deprecate "Broadcast RGB" and a a more neutral sounding 
"preferred color range", with the more neutral
sounding "limited" option instead of "Limited 16:235"
    - What's the relation between the 2? pq mentioned on the amdgpu gitlab that 
there is a posibility for userspace to
have only the new or the old one shown
    - Alternatively ignore "Broadcast RGB" when "preferred color range" is set 
and have them coexist?

>
> That is surprising. If this is truly wanted, then the documentation of
> "Broadcast RGB" must say that it applies to YCbCr too.
>
> Does amdgpu do the same as intel wrt. to the question about whose
> responsibility it is to make the pixels at the connector to match the
> set range?

I guess the kernel driver does the conversion, but i have to check for both.

For Intel I did not change the behavior of Boradcast RGB, but i think it's not 
clearly specified in the docs where the
conversion happens.

>
>
> Thanks,
> pq
>
>>  } else {
>> -if (dc_crtc_timing->flags.Y_ONLY)
>> +if (dc_crtc_timing->flags.Y_ONLY
>> +|| preferred_color_range ==
>> +
>> DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>>  color_space =
>>  COLOR_SPACE_YCBCR601_LIMITED;
>>  else
>> @@ -5283,7 +5288,10 @@ get_output_color_space(const struct dc_crtc_timing 
>> *dc_crtc_timing)
>>  }
>>  break;
>>  case PIXEL_ENCODING_RGB:
>> -color_space = COLOR_SPACE_SRGB;
>> +if (preferred_color_range == 
>> DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>> +color_space = COLOR_SPACE_SRGB_LIMITED;
>> +else
>> +color_space = COLOR_SPACE_SRGB;
>>  break;
>>  
>>  default:
>> @@ -5429,7 +5437,10 @@ static void 
>> fill_stream_properties_from_drm_display_mode(
>>  
>>  timing_out-&g

[Intel-gfx] [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property

2021-06-18 Thread Werner Sembach
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 9ffd2f9d3d75..c5dbf948a47a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5252,7 +5252,8 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
 }
 
 static enum dc_color_space
-get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
+get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
+  enum drm_mode_color_range preferred_color_range)
 {
enum dc_color_space color_space = COLOR_SPACE_SRGB;
 
@@ -5267,13 +5268,17 @@ get_output_color_space(const struct dc_crtc_timing 
*dc_crtc_timing)
 * respectively
 */
if (dc_crtc_timing->pix_clk_100hz > 270300) {
-   if (dc_crtc_timing->flags.Y_ONLY)
+   if (dc_crtc_timing->flags.Y_ONLY
+   || preferred_color_range ==
+   
DRM_MODE_COLOR_RANGE_LIMITED_16_235)
color_space =
COLOR_SPACE_YCBCR709_LIMITED;
else
color_space = COLOR_SPACE_YCBCR709;
} else {
-   if (dc_crtc_timing->flags.Y_ONLY)
+   if (dc_crtc_timing->flags.Y_ONLY
+   || preferred_color_range ==
+   
DRM_MODE_COLOR_RANGE_LIMITED_16_235)
color_space =
COLOR_SPACE_YCBCR601_LIMITED;
else
@@ -5283,7 +5288,10 @@ get_output_color_space(const struct dc_crtc_timing 
*dc_crtc_timing)
}
break;
case PIXEL_ENCODING_RGB:
-   color_space = COLOR_SPACE_SRGB;
+   if (preferred_color_range == 
DRM_MODE_COLOR_RANGE_LIMITED_16_235)
+   color_space = COLOR_SPACE_SRGB_LIMITED;
+   else
+   color_space = COLOR_SPACE_SRGB;
break;
 
default:
@@ -5429,7 +5437,10 @@ static void fill_stream_properties_from_drm_display_mode(
 
timing_out->aspect_ratio = get_aspect_ratio(mode_in);
 
-   stream->output_color_space = get_output_color_space(timing_out);
+   stream->output_color_space = get_output_color_space(timing_out,
+   connector_state ?
+   
connector_state->preferred_color_range :
+   
DRM_MODE_COLOR_RANGE_UNSET);
 
stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
@@ -7780,6 +7791,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
drm_connector_attach_active_bpc_property(>base, 8, 
16);

drm_connector_attach_preferred_color_format_property(>base);

drm_connector_attach_active_color_format_property(>base);
+   
drm_connector_attach_preferred_color_range_property(>base);

drm_connector_attach_active_color_range_property(>base);
}
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 2563788ba95a..80e1389fd0ec 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -421,6 +421,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_color_format_property)

drm_connector_attach_active_color_format_property(>base);
 
+   connector->preferred_color_range_property = 
master->base.preferred_color_range_property;
+   if (connector->preferred_color_range_property)
+   
drm_connector_attach_preferred_color_range_property(>base);
+
connector->active_color_range_property = 
master->base.active_color_range_property;
if (connector->active_color_range_property)

drm_connector_attach_active_color_range_property(>base);
-- 
2.25.1

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


[Intel-gfx] [PATCH v4 14/17] drm/i915/display: Add handling for new "preferred color format" property

2021-06-18 Thread Werner Sembach
This commit implements the "preferred color format" drm property for the
Intel GPU driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c   | 6 ++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 214010f7cbec..4c01ab887904 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -616,9 +616,12 @@ intel_dp_output_format(struct drm_connector *connector,
 {
struct intel_dp *intel_dp = 
intel_attached_dp(to_intel_connector(connector));
const struct drm_display_info *info = >display_info;
+   const struct drm_connector_state *connector_state = connector->state;
 
if (!connector->ycbcr_420_allowed ||
-   !drm_mode_is_420_only(info, mode))
+   !(drm_mode_is_420_only(info, mode) ||
+   (drm_mode_is_420_also(info, mode) && connector_state &&
+   connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB420)))
return INTEL_OUTPUT_FORMAT_RGB;
 
if (intel_dp->dfp.rgb_to_ycbcr &&
@@ -4691,11 +4694,13 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
+   drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
drm_connector_attach_active_color_range_property(connector);
} else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
+   drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
drm_connector_attach_active_color_range_property(connector);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index cb876175258f..67f0fb649876 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -856,6 +856,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(connector, 6, 12);
 
+   connector->preferred_color_format_property =
+   
intel_dp->attached_connector->base.preferred_color_format_property;
+   if (connector->preferred_color_format_property)
+   drm_connector_attach_preferred_color_format_property(connector);
+
connector->active_color_format_property =
intel_dp->attached_connector->base.active_color_format_property;
if (connector->active_color_format_property)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index dacac23a6c30..bce253bc5b16 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2153,6 +2153,11 @@ static int intel_hdmi_compute_output_format(struct 
intel_encoder *encoder,
crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
}
 
+   if (connector->ycbcr_420_allowed &&
+   conn_state->preferred_color_format == DRM_COLOR_FORMAT_YCRCB420 &&
+   drm_mode_is_420_also(>display_info, adjusted_mode))
+   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+
ret = intel_hdmi_compute_clock(encoder, crtc_state);
if (ret) {
if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420 &&
@@ -2516,6 +2521,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
drm_connector_attach_active_bpc_property(connector, 8, 12);
+   drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
drm_connector_attach_active_color_range_property(connector);
}
-- 
2.25.1

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


[Intel-gfx] [PATCH v4 16/17] drm/i915/display: Use the general "Broadcast RGB" implementation

2021-06-18 Thread Werner Sembach
Change from the i915 specific "Broadcast RGB" drm property implementation
to the general one.

This commit delete all traces of the former "Broadcast RGB" implementation
and add a new one using the new driver agnoistic functions an variables.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_atomic.c   |  8 --
 .../gpu/drm/i915/display/intel_connector.c| 28 ---
 .../gpu/drm/i915/display/intel_connector.h|  1 -
 .../drm/i915/display/intel_display_types.h|  8 --
 drivers/gpu/drm/i915/display/intel_dp.c   |  9 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  6 +++-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  8 ++
 drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   |  1 -
 9 files changed, 12 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index b4e7ac51aa31..f8d5a0e287b0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -63,8 +63,6 @@ int intel_digital_connector_atomic_get_property(struct 
drm_connector *connector,
 
if (property == dev_priv->force_audio_property)
*val = intel_conn_state->force_audio;
-   else if (property == dev_priv->broadcast_rgb_property)
-   *val = intel_conn_state->broadcast_rgb;
else {
drm_dbg_atomic(_priv->drm,
   "Unknown property [PROP:%d:%s]\n",
@@ -99,11 +97,6 @@ int intel_digital_connector_atomic_set_property(struct 
drm_connector *connector,
return 0;
}
 
-   if (property == dev_priv->broadcast_rgb_property) {
-   intel_conn_state->broadcast_rgb = val;
-   return 0;
-   }
-
drm_dbg_atomic(_priv->drm, "Unknown property [PROP:%d:%s]\n",
   property->base.id, property->name);
return -EINVAL;
@@ -134,7 +127,6 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
 * up in a modeset.
 */
if (new_conn_state->force_audio != old_conn_state->force_audio ||
-   new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.colorspace != old_conn_state->base.colorspace 
||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c 
b/drivers/gpu/drm/i915/display/intel_connector.c
index 9bed1ccecea0..89f0edf19182 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -241,34 +241,6 @@ intel_attach_force_audio_property(struct drm_connector 
*connector)
drm_object_attach_property(>base, prop, 0);
 }
 
-static const struct drm_prop_enum_list broadcast_rgb_names[] = {
-   { INTEL_BROADCAST_RGB_AUTO, "Automatic" },
-   { INTEL_BROADCAST_RGB_FULL, "Full" },
-   { INTEL_BROADCAST_RGB_LIMITED, "Limited 16:235" },
-};
-
-void
-intel_attach_broadcast_rgb_property(struct drm_connector *connector)
-{
-   struct drm_device *dev = connector->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct drm_property *prop;
-
-   prop = dev_priv->broadcast_rgb_property;
-   if (prop == NULL) {
-   prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
-  "Broadcast RGB",
-  broadcast_rgb_names,
-  ARRAY_SIZE(broadcast_rgb_names));
-   if (prop == NULL)
-   return;
-
-   dev_priv->broadcast_rgb_property = prop;
-   }
-
-   drm_object_attach_property(>base, prop, 0);
-}
-
 void
 intel_attach_aspect_ratio_property(struct drm_connector *connector)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_connector.h 
b/drivers/gpu/drm/i915/display/intel_connector.h
index 661a37a3c6d8..f3058a035476 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.h
+++ b/drivers/gpu/drm/i915/display/intel_connector.h
@@ -28,7 +28,6 @@ int intel_connector_update_modes(struct drm_connector 
*connector,
 struct edid *edid);
 int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *adapter);
 void intel_attach_force_audio_property(struct drm_connector *connector);
-void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
 void intel_attach_aspect_ratio_property(struct drm_connector *connector);
 void intel_attach_hdmi_colorspace_property(struct drm_connector *connector);
 void intel_atta

[Intel-gfx] [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context

2021-06-18 Thread Werner Sembach
Add "Broadcast RGB" to general drm context so that more drivers besides
i915 and gma500 can implement it without duplicating code.

Userspace can use this property to tell the graphic driver to use full or
limited color range for a given connector, overwriting the default
behaviour/automatic detection.

Possible options are:
- Automatic (default/current behaviour)
- Full
- Limited 16:235

In theory the driver should be able to automatically detect the monitors
capabilities, but because of flawed standard implementations in Monitors,
this might fail. In this case a manual overwrite is required to not have
washed out colors or lose details in very dark or bright scenes.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_atomic_helper.c |  4 +++
 drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
 drivers/gpu/drm/drm_connector.c | 43 +
 include/drm/drm_connector.h | 16 +++
 4 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 90d62f305257..0c89d32efbd0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->preferred_color_format !=
new_connector_state->preferred_color_format)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->preferred_color_range !=
+   new_connector_state->preferred_color_range)
+   new_crtc_state->connectors_changed = true;
}
 
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index c536f5e22016..c589bb1a8163 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->max_requested_bpc = val;
} else if (property == connector->preferred_color_format_property) {
state->preferred_color_format = val;
+   } else if (property == connector->preferred_color_range_property) {
+   state->preferred_color_range = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->max_requested_bpc;
} else if (property == connector->preferred_color_format_property) {
*val = state->preferred_color_format;
+   } else if (property == connector->preferred_color_range_property) {
+   *val = state->preferred_color_range;
} 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 aea03dd02e33..9bc596638613 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -905,6 +905,12 @@ static const struct drm_prop_enum_list 
drm_active_color_format_enum_list[] = {
{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
 };
 
+static const struct drm_prop_enum_list drm_preferred_color_range_enum_list[] = 
{
+   { DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
+   { DRM_MODE_COLOR_RANGE_FULL, "Full" },
+   { DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
+};
+
 static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
@@ -1243,6 +1249,13 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * drm_connector_attach_active_color_format_property() to install this
  * property.
  *
+ * Broadcast RGB:
+ * This property is used by userspace to change the used color range. When
+ * used the driver will use the selected range if valid for the current
+ * color format. Drivers to use the function
+ * drm_connector_attach_preferred_color_format_property() to create and
+ * attach the property to the connector during initialization.
+ *
  * active color range:
  * This read-only property tells userspace the color range actually used by
  * the hardware display engine on "the cable" on a connector. The chosen
@@ -2324,6 +2337,36 @@ void 
drm_connector_set_active_color_format_property(struct drm_connector *connec
 }
 EXPORT_SYMBOL(drm_connector_set_active_color_format

[Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-06-18 Thread Werner Sembach
Add a new general drm property "preferred color format" which can be used
by userspace to tell the graphic drivers to which color format to use.

Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (not supported by both amdgpu and i915)
- ycbcr420

In theory the auto option should choose the best available option for the
current setup, but because of bad internal conversion some monitors look
better with rgb and some with ycbcr444.

Also, because of bad shielded connectors and/or cables, it might be
preferable to use the less bandwidth heavy ycbcr422 and ycbcr420 formats
for a signal that is less deceptible to interference.

In the future, automatic color calibration for screens might also depend on
this option being available.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_atomic_helper.c |  4 +++
 drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
 drivers/gpu/drm/drm_connector.c | 48 -
 include/drm/drm_connector.h | 17 ++
 4 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index bc3487964fb5..90d62f305257 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -687,6 +687,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->max_requested_bpc !=
new_connector_state->max_requested_bpc)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->preferred_color_format !=
+   new_connector_state->preferred_color_format)
+   new_crtc_state->connectors_changed = true;
}
 
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 438e9585b225..c536f5e22016 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -796,6 +796,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
   fence_ptr);
} else if (property == connector->max_bpc_property) {
state->max_requested_bpc = val;
+   } else if (property == connector->preferred_color_format_property) {
+   state->preferred_color_format = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -873,6 +875,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->preferred_color_format_property) {
+   *val = state->preferred_color_format;
} 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 818de58d972f..aea03dd02e33 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -889,6 +889,14 @@ static const struct drm_prop_enum_list 
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native,  "Native"}, /* DP */
 };
 
+static const struct drm_prop_enum_list drm_preferred_color_format_enum_list[] 
= {
+   { 0, "auto" },
+   { DRM_COLOR_FORMAT_RGB444, "rgb" },
+   { DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
+   { DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
+   { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
+};
+
 static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
{ 0, "unknown" },
{ DRM_COLOR_FORMAT_RGB444, "rgb" },
@@ -1219,11 +1227,19 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * Drivers shall use drm_connector_attach_active_bpc_property() to install
  * this property.
  *
+ * preferred color format:
+ * This property is used by userspace to change the used color format. When
+ * used the driver will use the selected format if valid for the hardware,
+ * sink, and current resolution and refresh rate combination. Drivers to
+ * use the function drm_connector_attach_preferred_color_format_property()
+ * to create and attach the property to the connector during
+ * initialization.
+ *
  * active color format:
  * This read-only property tells userspace the color format actually used
  * by the hardware display engine

[Intel-gfx] [PATCH v4 11/17] drm/i915/display: Add handling for new "active color range" property

2021-06-18 Thread Werner Sembach
This commit implements the "active color range" drm property for the Intel
GPU driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 6 ++
 drivers/gpu/drm/i915/display/intel_dp.c  | 2 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c  | 5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c| 1 +
 4 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 57bec7f452d8..3d0bdca70c6a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10938,9 +10938,15 @@ static int intel_atomic_commit(struct drm_device *dev,

drm_connector_set_active_color_format_property(connector,

convert_intel_output_format_into_drm_color_format(
new_crtc_state->output_format));
+   drm_connector_set_active_color_range_property(connector,
+   new_crtc_state->limited_color_range ?
+   DRM_MODE_COLOR_RANGE_LIMITED_16_235 :
+   DRM_MODE_COLOR_RANGE_FULL);
} else {
drm_connector_set_active_bpc_property(connector, 0);

drm_connector_set_active_color_format_property(connector, 0);
+   drm_connector_set_active_color_range_property(connector,
+ 
DRM_MODE_COLOR_RANGE_UNSET);
}
}
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 9204bc14590a..214010f7cbec 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4692,10 +4692,12 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
drm_connector_attach_active_color_format_property(connector);
+   drm_connector_attach_active_color_range_property(connector);
} else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
drm_connector_attach_active_color_format_property(connector);
+   drm_connector_attach_active_color_range_property(connector);
}
 
/* Register HDMI colorspace for case of lspcon */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 3e4237df3360..cb876175258f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -861,6 +861,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_color_format_property)
drm_connector_attach_active_color_format_property(connector);
 
+   connector->active_color_range_property =
+   intel_dp->attached_connector->base.active_color_range_property;
+   if (connector->active_color_range_property)
+   drm_connector_attach_active_color_range_property(connector);
+
return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 367aba57b55f..dacac23a6c30 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2517,6 +2517,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
drm_connector_attach_max_bpc_property(connector, 8, 12);
drm_connector_attach_active_bpc_property(connector, 8, 12);
drm_connector_attach_active_color_format_property(connector);
+   drm_connector_attach_active_color_range_property(connector);
}
 }
 
-- 
2.25.1

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


[Intel-gfx] [PATCH v4 13/17] drm/amd/display: Add handling for new "preferred color format" property

2021-06-18 Thread Werner Sembach
This commit implements the "preferred color format" drm property for the
AMD GPU driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 +++
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +++
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index bce47f28e20a..9ffd2f9d3d75 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5351,15 +5351,32 @@ static void 
fill_stream_properties_from_drm_display_mode(
timing_out->h_border_right = 0;
timing_out->v_border_top = 0;
timing_out->v_border_bottom = 0;
-   /* TODO: un-hardcode */
-   if (drm_mode_is_420_only(info, mode_in)
-   || (drm_mode_is_420_also(info, mode_in) && 
aconnector->force_yuv420_output))
+
+   if (connector_state
+   && (connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB420
+   || aconnector->force_yuv420_output) && 
drm_mode_is_420(info, mode_in))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
-   else if ((connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
-   && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+   else if (connector_state
+   && connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB444
+   && connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
-   else
+   else if (connector_state
+   && connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_RGB444
+   && !drm_mode_is_420_only(info, mode_in))
timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
+   else
+   /*
+* connector_state->preferred_color_format not possible
+* || connector_state->preferred_color_format == 0 (auto)
+* || connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB422
+*/
+   if (drm_mode_is_420_only(info, mode_in))
+   timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
+   else if ((connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
+   && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+   timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
+   else
+   timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
 
timing_out->timing_3d_format = TIMING_3D_FORMAT_NONE;
timing_out->display_color_depth = convert_color_depth_from_display_info(
@@ -7761,6 +7778,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   
drm_connector_attach_preferred_color_format_property(>base);

drm_connector_attach_active_color_format_property(>base);

drm_connector_attach_active_color_range_property(>base);
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index b5d57bbbdd20..2563788ba95a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -413,6 +413,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(>base, 8, 
16);
 
+   connector->preferred_color_format_property = 
master->base.preferred_color_format_property;
+   if (connector->preferred_color_format_property)
+   
drm_connector_attach_preferred_color_format_property(>base);
+
connector->active_color_format_property = 
master->base.active_color_format_property;
if (connector->active_color_format_property)

drm_connector_attach_active_color_format_property(>base);
-- 
2.25.1

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


[Intel-gfx] [PATCH v4 10/17] drm/amd/display: Add handling for new "active color range" property

2021-06-18 Thread Werner Sembach
This commit implements the "active color range" drm property for the AMD
GPU driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 +++
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5086d6d74bf6..bce47f28e20a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6733,6 +6733,33 @@ static int 
convert_dc_pixel_encoding_into_drm_color_format(
return 0;
 }
 
+static int convert_dc_color_space_into_drm_mode_color_range(enum 
dc_color_space color_space)
+{
+   if (color_space == COLOR_SPACE_SRGB ||
+   color_space == COLOR_SPACE_XR_RGB ||
+   color_space == COLOR_SPACE_MSREF_SCRGB ||
+   color_space == COLOR_SPACE_2020_RGB_FULLRANGE ||
+   color_space == COLOR_SPACE_ADOBERGB ||
+   color_space == COLOR_SPACE_DCIP3 ||
+   color_space == COLOR_SPACE_DOLBYVISION ||
+   color_space == COLOR_SPACE_YCBCR601 ||
+   color_space == COLOR_SPACE_XV_YCC_601 ||
+   color_space == COLOR_SPACE_YCBCR709 ||
+   color_space == COLOR_SPACE_XV_YCC_709 ||
+   color_space == COLOR_SPACE_2020_YCBCR ||
+   color_space == COLOR_SPACE_YCBCR709_BLACK ||
+   color_space == COLOR_SPACE_DISPLAYNATIVE ||
+   color_space == COLOR_SPACE_APPCTRL ||
+   color_space == COLOR_SPACE_CUSTOMPOINTS)
+   return DRM_MODE_COLOR_RANGE_FULL;
+   if (color_space == COLOR_SPACE_SRGB_LIMITED ||
+   color_space == COLOR_SPACE_2020_RGB_LIMITEDRANGE ||
+   color_space == COLOR_SPACE_YCBCR601_LIMITED ||
+   color_space == COLOR_SPACE_YCBCR709_LIMITED)
+   return DRM_MODE_COLOR_RANGE_LIMITED_16_235;
+   return DRM_MODE_COLOR_RANGE_UNSET;
+}
+
 static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
  struct drm_crtc_state *crtc_state,
  struct drm_connector_state 
*conn_state)
@@ -7735,6 +7762,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8, 
16);

drm_connector_attach_active_color_format_property(>base);
+   
drm_connector_attach_active_color_range_property(>base);
}
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
@@ -9118,10 +9146,15 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)

drm_connector_set_active_color_format_property(connector,

convert_dc_pixel_encoding_into_drm_color_format(

dm_new_crtc_state->stream->timing.pixel_encoding));
+   
drm_connector_set_active_color_range_property(connector,
+   
convert_dc_color_space_into_drm_mode_color_range(
+   
dm_new_crtc_state->stream->output_color_space));
}
} else {
drm_connector_set_active_bpc_property(connector, 0);

drm_connector_set_active_color_format_property(connector, 0);
+   drm_connector_set_active_color_range_property(connector,
+ 
DRM_MODE_COLOR_RANGE_UNSET);
}
}
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 13151d13aa73..b5d57bbbdd20 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -417,6 +417,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_color_format_property)

drm_connector_attach_active_color_format_property(>base);
 
+   connector->active_color_range_property = 
master->base.active_color_range_property;
+   if (connector->active_color_range_property)
+   
drm_connector_attach_active_color_range_property(>base);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1

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


[Intel-gfx] [PATCH v4 05/17] drm/i915/display: Add handling for new "active bpc" property

2021-06-18 Thread Werner Sembach
This commit implements the "active bpc" drm property for the Intel GPU
driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 17 +
 drivers/gpu/drm/i915/display/intel_dp.c  |  7 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c|  4 +++-
 4 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 6be1b31af07b..4b00d2f3b3c8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10839,6 +10839,9 @@ static int intel_atomic_commit(struct drm_device *dev,
 {
struct intel_atomic_state *state = to_intel_atomic_state(_state);
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_connector *connector;
+   struct drm_connector_state *new_conn_state;
+   int i;
int ret = 0;
 
state->wakeref = intel_runtime_pm_get(_priv->runtime_pm);
@@ -10907,6 +10910,20 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
 
+   /* Extract information from crtc to communicate it to userspace as 
connector properties */
+   for_each_new_connector_in_state(>base, connector, 
new_conn_state, i) {
+   struct intel_crtc *crtc = to_intel_crtc(new_conn_state->crtc);
+
+   if (crtc) {
+   struct intel_crtc_state *new_crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
+
+   drm_connector_set_active_bpc_property(connector,
+   new_crtc_state->pipe_bpp / 3);
+   } else
+   drm_connector_set_active_bpc_property(connector, 0);
+   }
+
drm_atomic_state_get(>base);
INIT_WORK(>base.commit_work, intel_atomic_commit_work);
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c983044..2d7b5318ae7b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4688,10 +4688,13 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
intel_attach_force_audio_property(connector);
 
intel_attach_broadcast_rgb_property(connector);
-   if (HAS_GMCH(dev_priv))
+   if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
-   else if (DISPLAY_VER(dev_priv) >= 5)
+   drm_connector_attach_active_bpc_property(connector, 6, 10);
+   } else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_bpc_property(connector, 6, 12);
+   }
 
/* Register HDMI colorspace for case of lspcon */
if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index b170e272bdee..16bfc59570a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -851,6 +851,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->max_bpc_property)
drm_connector_attach_max_bpc_property(connector, 6, 12);
 
+   connector->active_bpc_property =
+   intel_dp->attached_connector->base.active_bpc_property;
+   if (connector->active_bpc_property)
+   drm_connector_attach_active_bpc_property(connector, 6, 12);
+
return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 7e51c98c475e..9160e21ac9d6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2513,8 +2513,10 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
if (DISPLAY_VER(dev_priv) >= 10)
drm_connector_attach_hdr_output_metadata_property(connector);
 
-   if (!HAS_GMCH(dev_priv))
+   if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
+   drm_connector_attach_active_bpc_property(connector, 8, 12);
+   }
 }
 
 /*
-- 
2.25.1

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


[Intel-gfx] [PATCH v4 07/17] drm/amd/display: Add handling for new "active color format" property

2021-06-18 Thread Werner Sembach
This commit implements the "active color format" drm property for the AMD
GPU driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +--
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +++
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b6293b3104ed..5086d6d74bf6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6715,6 +6715,24 @@ static int convert_dc_color_depth_into_bpc (enum 
dc_color_depth display_color_de
return 0;
 }
 
+static int convert_dc_pixel_encoding_into_drm_color_format(
+   enum dc_pixel_encoding display_pixel_encoding)
+{
+   switch (display_pixel_encoding) {
+   case PIXEL_ENCODING_RGB:
+   return DRM_COLOR_FORMAT_RGB444;
+   case PIXEL_ENCODING_YCBCR422:
+   return DRM_COLOR_FORMAT_YCRCB422;
+   case PIXEL_ENCODING_YCBCR444:
+   return DRM_COLOR_FORMAT_YCRCB444;
+   case PIXEL_ENCODING_YCBCR420:
+   return DRM_COLOR_FORMAT_YCRCB420;
+   default:
+   break;
+   }
+   return 0;
+}
+
 static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
  struct drm_crtc_state *crtc_state,
  struct drm_connector_state 
*conn_state)
@@ -7716,6 +7734,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   
drm_connector_attach_active_color_format_property(>base);
}
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
@@ -9092,12 +9111,18 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
if (crtc) {
new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
-   if (dm_new_crtc_state->stream)
+   if (dm_new_crtc_state->stream) {
drm_connector_set_active_bpc_property(connector,
convert_dc_color_depth_into_bpc(

dm_new_crtc_state->stream->timing.display_color_depth));
-   } else
+   
drm_connector_set_active_color_format_property(connector,
+   
convert_dc_pixel_encoding_into_drm_color_format(
+   
dm_new_crtc_state->stream->timing.pixel_encoding));
+   }
+   } else {
drm_connector_set_active_bpc_property(connector, 0);
+   
drm_connector_set_active_color_format_property(connector, 0);
+   }
}
 
/* Count number of newly disabled CRTCs for dropping PM refs later. */
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 0cf38743ec47..13151d13aa73 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -413,6 +413,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(>base, 8, 
16);
 
+   connector->active_color_format_property = 
master->base.active_color_format_property;
+   if (connector->active_color_format_property)
+   
drm_connector_attach_active_color_format_property(>base);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1

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


[Intel-gfx] [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

2021-06-18 Thread Werner Sembach
Add a new general drm property "active color range" which can be used by
graphic drivers to report the used color range back to userspace.

There was no way to check which color range got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor and what the default behaviour of the used driver is. This
property helps eliminating the guessing at this point.

In the future, automatic color calibration for screens might also depend on
this information being available.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_connector.c | 59 +
 include/drm/drm_connector.h | 27 +++
 2 files changed, 86 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 684d7abdf0eb..818de58d972f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -897,6 +897,12 @@ static const struct drm_prop_enum_list 
drm_active_color_format_enum_list[] = {
{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
 };
 
+static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
+   { DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
+   { DRM_MODE_COLOR_RANGE_FULL, "Full" },
+   { DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
+};
+
 DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 drm_dp_subconnector_enum_list)
 
@@ -1221,6 +1227,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * drm_connector_attach_active_color_format_property() to install this
  * property.
  *
+ * active color range:
+ * This read-only property tells userspace the color range actually used by
+ * the hardware display engine on "the cable" on a connector. The chosen
+ * value depends on hardware capabilities of the monitor and the used color
+ * format. Drivers shall use
+ * drm_connector_attach_active_color_range_property() to install this
+ * property.
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -2264,6 +2278,51 @@ void 
drm_connector_set_active_color_format_property(struct drm_connector *connec
 }
 EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
 
+/**
+ * drm_connector_attach_active_color_range_property - attach "active color 
range" property
+ * @connector: connector to attach active color range property on.
+ *
+ * This is used to check the applied color range on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_range_property(struct drm_connector 
*connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   if (!connector->active_color_range_property) {
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, 
"active color range",
+   
drm_active_color_range_enum_list,
+   
ARRAY_SIZE(drm_active_color_range_enum_list));
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_color_range_property = prop;
+   drm_object_attach_property(>base, prop, 
DRM_MODE_COLOR_RANGE_UNSET);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_range_property);
+
+/**
+ * drm_connector_set_active_color_range_property - sets the active color range 
property for a
+ * connector
+ * @connector: drm connector
+ * @active_color_range: color range for the connector currently active on "the 
cable"
+ *
+ * Should be used by atomic drivers to update the active color range over a 
connector.
+ */
+void drm_connector_set_active_color_range_property(struct drm_connector 
*connector,
+  enum drm_mode_color_range 
active_color_range)
+{
+   drm_object_property_set_value(>base, 
connector->active_color_range_property,
+ active_color_range);
+}
+EXPORT_SYMBOL(drm_connector_set_active_color_range_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach 
"HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 8a5197f14e87..9fb7119b7a02 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -648,6 +648,24 @@ struct drm_tv_connector_state {
unsigned int hue;
 };
 
+/**
+ * enum drm_mode_color_range - color_range info for _connector
+ *
+ * This enum is used to represent full or limited color range on the display
+ * connector signal.
+ *
+ * @DRM_MODE_COLOR_RANGE_UNSET:Color range is 
unspecified/default.
+ * @DRM_MODE_COLOR_RANGE_FULL: Color range is full range, 0-255 for

[Intel-gfx] [PATCH v4 06/17] drm/uAPI: Add "active color format" drm property as feedback for userspace

2021-06-18 Thread Werner Sembach
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.

There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor, the GPU, and the connection used and what the default
behaviour of the used driver is (e.g. amdgpu prefers YCbCr 4:4:4 while i915
prefers RGB). This property helps eliminating the guessing on this point.

In the future, automatic color calibration for screens might also depend on
this information being available.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_connector.c | 61 +
 include/drm/drm_connector.h |  9 +
 2 files changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 943f6b61053b..684d7abdf0eb 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -889,6 +889,14 @@ static const struct drm_prop_enum_list 
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native,  "Native"}, /* DP */
 };
 
+static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
+   { 0, "unknown" },
+   { DRM_COLOR_FORMAT_RGB444, "rgb" },
+   { DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
+   { DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
+   { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
+};
+
 DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 drm_dp_subconnector_enum_list)
 
@@ -1205,6 +1213,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * Drivers shall use drm_connector_attach_active_bpc_property() to install
  * this property.
  *
+ * active color format:
+ * This read-only property tells userspace the color format 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. Drivers shall use
+ * drm_connector_attach_active_color_format_property() to install this
+ * property.
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -2203,6 +2219,51 @@ void drm_connector_set_active_bpc_property(struct 
drm_connector *connector, int
 }
 EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
 
+/**
+ * drm_connector_attach_active_color_format_property - attach "active color 
format" property
+ * @connector: connector to attach active color format property on.
+ *
+ * This is used to check the applied color format on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_format_property(struct drm_connector 
*connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   if (!connector->active_color_format_property) {
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, 
"active color format",
+   
drm_active_color_format_enum_list,
+   
ARRAY_SIZE(drm_active_color_format_enum_list));
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_color_format_property = prop;
+   drm_object_attach_property(>base, prop, 0);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_format_property);
+
+/**
+ * drm_connector_set_active_color_format_property - sets the active color 
format property for a
+ * connector
+ * @connector: drm connector
+ * @active_color_format: color format for the connector currently active on 
"the cable"
+ *
+ * Should be used by atomic drivers to update the active color format over a 
connector.
+ */
+void drm_connector_set_active_color_format_property(struct drm_connector 
*connector,
+   u32 active_color_format)
+{
+   drm_object_property_set_value(>base, 
connector->active_color_format_property,
+ active_color_format);
+}
+EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach 
"HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index eee86de62a5f..8a5197f14e87 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1386,6 +1386,12 @@ struct drm_connector {
 */
struct drm_property *active_bpc_property;
 
+   /**
+* @active_color_format_property: Default connector property for the
+* active color format to be driven out of the connector.
+*/
+ 

[Intel-gfx] [PATCH v4 08/17] drm/i915/display: Add handling for new "active color format" property

2021-06-18 Thread Werner Sembach
This commit implements the "active color format" drm property for the Intel
GPU driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 22 +++-
 drivers/gpu/drm/i915/display/intel_dp.c  |  2 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c|  1 +
 4 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 4b00d2f3b3c8..57bec7f452d8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10609,6 +10609,21 @@ static void 
intel_atomic_prepare_plane_clear_colors(struct intel_atomic_state *s
}
 }
 
+static int convert_intel_output_format_into_drm_color_format(enum 
intel_output_format output_format)
+{
+   switch (output_format) {
+   case INTEL_OUTPUT_FORMAT_RGB:
+   return DRM_COLOR_FORMAT_RGB444;
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   return DRM_COLOR_FORMAT_YCRCB420;
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   return DRM_COLOR_FORMAT_YCRCB444;
+   default:
+   break;
+   }
+   return 0;
+}
+
 static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 {
struct drm_device *dev = state->base.dev;
@@ -10920,8 +10935,13 @@ static int intel_atomic_commit(struct drm_device *dev,
 
drm_connector_set_active_bpc_property(connector,
new_crtc_state->pipe_bpp / 3);
-   } else
+   
drm_connector_set_active_color_format_property(connector,
+   
convert_intel_output_format_into_drm_color_format(
+   new_crtc_state->output_format));
+   } else {
drm_connector_set_active_bpc_property(connector, 0);
+   
drm_connector_set_active_color_format_property(connector, 0);
+   }
}
 
drm_atomic_state_get(>base);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2d7b5318ae7b..9204bc14590a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4691,9 +4691,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
+   drm_connector_attach_active_color_format_property(connector);
} else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_color_format_property(connector);
}
 
/* Register HDMI colorspace for case of lspcon */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 16bfc59570a5..3e4237df3360 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -856,6 +856,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(connector, 6, 12);
 
+   connector->active_color_format_property =
+   intel_dp->attached_connector->base.active_color_format_property;
+   if (connector->active_color_format_property)
+   drm_connector_attach_active_color_format_property(connector);
+
return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 9160e21ac9d6..367aba57b55f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2516,6 +2516,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
drm_connector_attach_active_bpc_property(connector, 8, 12);
+   drm_connector_attach_active_color_format_property(connector);
}
 }
 
-- 
2.25.1

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


[Intel-gfx] [PATCH v4 04/17] drm/amd/display: Add handling for new "active bpc" property

2021-06-18 Thread Werner Sembach
This commit implements the "active bpc" drm property for the AMD GPU
driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 ++-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index cd1df5cf4815..b6293b3104ed 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7713,8 +7713,10 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
adev->mode_info.underscan_vborder_property,
0);
 
-   if (!aconnector->mst_port)
+   if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
+   drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   }
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
aconnector->base.state->max_bpc = (connector_type == 
DRM_MODE_CONNECTOR_eDP) ? 16 : 8;
@@ -9083,6 +9085,21 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
mutex_unlock(>dc_lock);
}
 
+   /* Extract information from crtc to communicate it to userspace as 
connector properties */
+   for_each_new_connector_in_state(state, connector, new_con_state, i) {
+   struct drm_crtc *crtc = new_con_state->crtc;
+
+   if (crtc) {
+   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
+   dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+   if (dm_new_crtc_state->stream)
+   drm_connector_set_active_bpc_property(connector,
+   convert_dc_color_depth_into_bpc(
+   
dm_new_crtc_state->stream->timing.display_color_depth));
+   } else
+   drm_connector_set_active_bpc_property(connector, 0);
+   }
+
/* Count number of newly disabled CRTCs for dropping PM refs later. */
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
  new_crtc_state, i) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 5568d4e518e6..0cf38743ec47 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -409,6 +409,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->max_bpc_property)
drm_connector_attach_max_bpc_property(connector, 8, 16);
 
+   connector->active_bpc_property = master->base.active_bpc_property;
+   if (connector->active_bpc_property)
+   drm_connector_attach_active_bpc_property(>base, 8, 
16);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1

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


[Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-18 Thread Werner Sembach
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 
---
 drivers/gpu/drm/drm_connector.c | 51 +
 include/drm/drm_connector.h |  8 ++
 2 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..943f6b61053b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1197,6 +1197,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:
@@ -2152,6 +2160,49 @@ 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;
+
+   if (!connector->active_bpc_property) {
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
"active bpc",
+min, max);
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_bpc_property = prop;
+   drm_object_attach_property(>base, prop, 0);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
+
+/**
+ * drm_connector_set_active_bpc_property - sets the active bits per color 
property for a connector
+ * @connector: drm connector
+ * @active_bpc: bits per color for the connector currently active on "the 
cable"
+ *
+ * Should be used by atomic drivers to update the active bits per color over a 
connector.
+ */
+void drm_connector_set_active_bpc_property(struct drm_connector *connector, 
int active_bpc)
+{
+   drm_object_property_set_value(>base, 
connector->active_bpc_property, active_bpc);
+}
+EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach 
"HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 714d1a01c065..eee86de62a5f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1380,6 +1380,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)
@@ -1702,6 +1708,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);
+void drm_connector_set_active_bpc_property(struct drm_connector *connector, 
int active_bpc);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
2.25.1

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


[Intel-gfx] [PATCH v4 02/17] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc

2021-06-18 Thread Werner Sembach
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to
an integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11
missing.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 44757720b15f..cd1df5cf4815 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6705,6 +6705,10 @@ static int convert_dc_color_depth_into_bpc (enum 
dc_color_depth display_color_de
return 14;
case COLOR_DEPTH_161616:
return 16;
+   case COLOR_DEPTH_999:
+   return 9;
+   case COLOR_DEPTH_11:
+   return 11;
default:
break;
}
-- 
2.25.1

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


[Intel-gfx] [PATCH v4 00/17] New uAPI drm properties for color management

2021-06-18 Thread Werner Sembach
Implementation of https://lkml.org/lkml/2021/5/12/764 now feature complete
albeit not fully tested.

I have not yet corrected the DSC behavior and double checked the dithering
behavior. I release the feature complete patch series now anyways so that
work on the userspace implementation can start.

I have no DP MST splitter at hand. I tried my best to not break anything,
but if one who has one could test it would be very helpful.

amdgpu in the former implementation was full color range only, albeit there
was a path prepared for limited color range on both rgb and ycbcr encoding,
which was never selected however. With the Broadcast RGB property, a user
can now select this program path.

On i915 Broadcast RGB still only affects rgb as ycbcr was and is always
limited with this driver, which I didn't change.

gma500 driver still uses it's own implementation of the "Broadcast RGB"
property, which doesn't have an "Automatic" setting. I too didn't touch
this as I can't test a corresponding card.


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


[Intel-gfx] [PATCH v4 01/17] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check

2021-06-18 Thread Werner Sembach
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.

Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports drm_mode_is_420_only() even on a non HDMI connection.

This patch also moves both checks in the same if-case. This  eliminates an
extra else-if-case.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6fda0dfb78f8..44757720b15f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5353,10 +5353,7 @@ static void fill_stream_properties_from_drm_display_mode(
timing_out->v_border_bottom = 0;
/* TODO: un-hardcode */
if (drm_mode_is_420_only(info, mode_in)
-   && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
-   timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
-   else if (drm_mode_is_420_also(info, mode_in)
-   && aconnector->force_yuv420_output)
+   || (drm_mode_is_420_also(info, mode_in) && 
aconnector->force_yuv420_output))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
else if ((connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
&& stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
-- 
2.25.1

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


Re: [Intel-gfx] [PATCH v3 03/14] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-15 Thread Werner Sembach

Am 15.06.21 um 16:14 schrieb Werner Sembach:

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 
---
  drivers/gpu/drm/drm_connector.c | 50 +
  include/drm/drm_connector.h |  8 ++
  2 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..02c310c1ac2d 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1197,6 +1197,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:
@@ -2152,6 +2160,48 @@ 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;
+
+   if (!connector->active_bpc_property) {
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
"active bpc", min, max);
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_bpc_property = prop;
+   drm_object_attach_property(>base, prop, 0);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
+
+/**
+ * drm_connector_set_active_bpc_property - sets the active bits per color 
property for a connector
+ * @connector: drm connector
+ * @active_bpc: bits per color for the connector currently active on "the 
cable"
+ *
+ * Should be used by atomic drivers to update the active bits per color over a 
connector.
+ */
+void drm_connector_set_active_bpc_property(struct drm_connector *connector, 
int active_bpc)
+{
+   drm_object_property_set_value(>base, 
connector->active_bpc_property, active_bpc);
+}
+EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
+
  /**
   * drm_connector_attach_hdr_output_metadata_property - attach 
"HDR_OUTPUT_METADA" property
   * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 714d1a01c065..eee86de62a5f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1380,6 +1380,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)
@@ -1702,6 +1708,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);
+void drm_connector_set_active_bpc_property(struct drm_connector *connector, 
int active_bpc);
  
  /**

   * struct drm_tile_group - Tile group metadata


I looked into DSC:

In both the amd and intel implementation it's:

max_bpc >= uncompressed bpc >= dsc bpc

Cu

[Intel-gfx] [PATCH v3 13/14] drm/amd/display: Add handling for new "preferred color format" property

2021-06-15 Thread Werner Sembach
This commit implements the "preferred color format" drm property for the AMD GPU
driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 705cd2e015af..ead246b2ec57 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5351,15 +5351,26 @@ static void 
fill_stream_properties_from_drm_display_mode(
timing_out->h_border_right = 0;
timing_out->v_border_top = 0;
timing_out->v_border_bottom = 0;
-   /* TODO: un-hardcode */
-   if (drm_mode_is_420_only(info, mode_in)
-   || (drm_mode_is_420_also(info, mode_in) && 
aconnector->force_yuv420_output))
+
+   if (connector_state && (connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB420
+   || aconnector->force_yuv420_output) && 
drm_mode_is_420(info, mode_in))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
-   else if ((connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
-   && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+   else if (connector_state && connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB444
+   && connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
-   else
+   else if (connector_state && connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_RGB444
+   && !drm_mode_is_420_only(info, mode_in))
timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
+   else /* connector_state->preferred_color_format not possible
+   || connector_state->preferred_color_format == 0 (auto)
+   || connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB422 */
+   if (drm_mode_is_420_only(info, mode_in))
+   timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
+   else if ((connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
+   && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+   timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
+   else
+   timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
 
timing_out->timing_3d_format = TIMING_3D_FORMAT_NONE;
timing_out->display_color_depth = convert_color_depth_from_display_info(
@@ -7760,6 +7771,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   
drm_connector_attach_preferred_color_format_property(>base);

drm_connector_attach_active_color_format_property(>base);

drm_connector_attach_active_color_range_property(>base);
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index b5d57bbbdd20..2563788ba95a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -413,6 +413,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(>base, 8, 
16);
 
+   connector->preferred_color_format_property = 
master->base.preferred_color_format_property;
+   if (connector->preferred_color_format_property)
+   
drm_connector_attach_preferred_color_format_property(>base);
+
connector->active_color_format_property = 
master->base.active_color_format_property;
if (connector->active_color_format_property)

drm_connector_attach_active_color_format_property(>base);
-- 
2.25.1

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


[Intel-gfx] [PATCH v3 14/14] drm/i915/display: Add handling for new "preferred color format" property

2021-06-15 Thread Werner Sembach
This commit implements the "preferred color format" drm property for the Intel 
GPU
driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c   | 5 +
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index d648582d0786..5c83ae624ad1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -616,9 +616,12 @@ intel_dp_output_format(struct drm_connector *connector,
 {
struct intel_dp *intel_dp = 
intel_attached_dp(to_intel_connector(connector));
const struct drm_display_info *info = >display_info;
+   const struct drm_connector_state *connector_state = connector->state;
 
if (!connector->ycbcr_420_allowed ||
-   !drm_mode_is_420_only(info, mode))
+   !(drm_mode_is_420_only(info, mode) ||
+   (drm_mode_is_420_also(info, mode) && connector_state &&
+   connector_state->preferred_color_format == 
DRM_COLOR_FORMAT_YCRCB420)))
return INTEL_OUTPUT_FORMAT_RGB;
 
if (intel_dp->dfp.rgb_to_ycbcr &&
@@ -4691,12 +4694,14 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
+   drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
drm_connector_attach_active_color_range_property(connector);
}
else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
+   drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
drm_connector_attach_active_color_range_property(connector);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index cb876175258f..67f0fb649876 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -856,6 +856,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(connector, 6, 12);
 
+   connector->preferred_color_format_property =
+   
intel_dp->attached_connector->base.preferred_color_format_property;
+   if (connector->preferred_color_format_property)
+   drm_connector_attach_preferred_color_format_property(connector);
+
connector->active_color_format_property =
intel_dp->attached_connector->base.active_color_format_property;
if (connector->active_color_format_property)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index dacac23a6c30..0d917d61482d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2153,6 +2153,10 @@ static int intel_hdmi_compute_output_format(struct 
intel_encoder *encoder,
crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
}
 
+   if (connector->ycbcr_420_allowed && conn_state->preferred_color_format 
== DRM_COLOR_FORMAT_YCRCB420 &&
+   drm_mode_is_420_also(>display_info, adjusted_mode))
+   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+
ret = intel_hdmi_compute_clock(encoder, crtc_state);
if (ret) {
if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420 &&
@@ -2516,6 +2520,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
drm_connector_attach_active_bpc_property(connector, 8, 12);
+   drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
drm_connector_attach_active_color_range_property(connector);
}
-- 
2.25.1

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


[Intel-gfx] [PATCH v3 08/14] drm/i915/display: Add handling for new "active color format" property

2021-06-15 Thread Werner Sembach
This commit implements the "active color format" drm property for the Intel GPU
driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 21 +++-
 drivers/gpu/drm/i915/display/intel_dp.c  |  2 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c|  1 +
 4 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index ee3669bd4662..2cf09599ddc3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10609,6 +10609,21 @@ static void 
intel_atomic_prepare_plane_clear_colors(struct intel_atomic_state *s
}
 }
 
+static int convert_intel_output_format_into_drm_color_format(enum 
intel_output_format output_format)
+{
+   switch (output_format) {
+   case INTEL_OUTPUT_FORMAT_RGB:
+   return DRM_COLOR_FORMAT_RGB444;
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   return DRM_COLOR_FORMAT_YCRCB420;
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   return DRM_COLOR_FORMAT_YCRCB444;
+   default:
+   break;
+   }
+   return 0;
+}
+
 static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 {
struct drm_device *dev = state->base.dev;
@@ -10916,9 +10931,13 @@ static int intel_atomic_commit(struct drm_device *dev,
if (crtc) {
struct intel_crtc_state *new_crtc_state = 
intel_atomic_get_new_crtc_state(state, crtc);
drm_connector_set_active_bpc_property(connector, 
new_crtc_state->pipe_bpp / 3);
+   
drm_connector_set_active_color_format_property(connector,
+   
convert_intel_output_format_into_drm_color_format(new_crtc_state->output_format));
}
-   else
+   else {
drm_connector_set_active_bpc_property(connector, 0);
+   
drm_connector_set_active_color_format_property(connector, 0);
+   }
}
 
drm_atomic_state_get(>base);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 404a27e56ceb..01fdb9141592 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4691,10 +4691,12 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
+   drm_connector_attach_active_color_format_property(connector);
}
else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_color_format_property(connector);
}
 
/* Register HDMI colorspace for case of lspcon */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 16bfc59570a5..3e4237df3360 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -856,6 +856,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(connector, 6, 12);
 
+   connector->active_color_format_property =
+   intel_dp->attached_connector->base.active_color_format_property;
+   if (connector->active_color_format_property)
+   drm_connector_attach_active_color_format_property(connector);
+
return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 9160e21ac9d6..367aba57b55f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2516,6 +2516,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
drm_connector_attach_active_bpc_property(connector, 8, 12);
+   drm_connector_attach_active_color_format_property(connector);
}
 }
 
-- 
2.25.1

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


[Intel-gfx] [PATCH v3 10/14] drm/amd/display: Add handling for new "active color range" property

2021-06-15 Thread Werner Sembach
This commit implements the "active color range" drm property for the AMD GPU
driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +++
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +++
 2 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b66336a1403e..705cd2e015af 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6732,6 +6732,33 @@ static int 
convert_dc_pixel_encoding_into_drm_color_format(enum dc_pixel_encodin
return 0;
 }
 
+static int convert_dc_color_space_into_drm_mode_color_range(enum 
dc_color_space color_space)
+{
+   if (color_space == COLOR_SPACE_SRGB ||
+   color_space == COLOR_SPACE_XR_RGB ||
+   color_space == COLOR_SPACE_MSREF_SCRGB ||
+   color_space == COLOR_SPACE_2020_RGB_FULLRANGE ||
+   color_space == COLOR_SPACE_ADOBERGB ||
+   color_space == COLOR_SPACE_DCIP3 ||
+   color_space == COLOR_SPACE_DOLBYVISION ||
+   color_space == COLOR_SPACE_YCBCR601 ||
+   color_space == COLOR_SPACE_XV_YCC_601 ||
+   color_space == COLOR_SPACE_YCBCR709 ||
+   color_space == COLOR_SPACE_XV_YCC_709 ||
+   color_space == COLOR_SPACE_2020_YCBCR ||
+   color_space == COLOR_SPACE_YCBCR709_BLACK ||
+   color_space == COLOR_SPACE_DISPLAYNATIVE ||
+   color_space == COLOR_SPACE_APPCTRL ||
+   color_space == COLOR_SPACE_CUSTOMPOINTS)
+   return DRM_MODE_COLOR_RANGE_FULL;
+   if (color_space == COLOR_SPACE_SRGB_LIMITED ||
+   color_space == COLOR_SPACE_2020_RGB_LIMITEDRANGE ||
+   color_space == COLOR_SPACE_YCBCR601_LIMITED ||
+   color_space == COLOR_SPACE_YCBCR709_LIMITED)
+   return DRM_MODE_COLOR_RANGE_LIMITED_16_235;
+   return DRM_MODE_COLOR_RANGE_UNSET;
+}
+
 static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
  struct drm_crtc_state *crtc_state,
  struct drm_connector_state 
*conn_state)
@@ -7734,6 +7761,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8, 
16);

drm_connector_attach_active_color_format_property(>base);
+   
drm_connector_attach_active_color_range_property(>base);
}
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
@@ -9116,11 +9144,15 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)

drm_connector_set_active_color_format_property(connector,

convert_dc_pixel_encoding_into_drm_color_format(

dm_new_crtc_state->stream->timing.pixel_encoding));
+   
drm_connector_set_active_color_range_property(connector,
+   
convert_dc_color_space_into_drm_mode_color_range(
+   
dm_new_crtc_state->stream->output_color_space));
}
}
else {
drm_connector_set_active_bpc_property(connector, 0);

drm_connector_set_active_color_format_property(connector, 0);
+   
drm_connector_set_active_color_range_property(connector, 
DRM_MODE_COLOR_RANGE_UNSET);
}
}
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 13151d13aa73..b5d57bbbdd20 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -417,6 +417,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_color_format_property)

drm_connector_attach_active_color_format_property(>base);
 
+   connector->active_color_range_property = 
master->base.active_color_range_property;
+   if (connector->active_color_range_property)
+   
drm_connector_attach_active_color_range_property(>base);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1

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


[Intel-gfx] [PATCH v3 12/14] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-06-15 Thread Werner Sembach
Add a new general drm property "preferred color format" which can be used by
userspace to tell the graphic drivers to which color format to use.

Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (not supported by both amdgpu and i915)
- ycbcr420

In theory the auto option should choose the best available option for the
current setup, but because of bad internal conversion some monitors look better
with rgb and some with ycbcr444.

Also, because of bad shielded connectors and/or cables, it might be preferable
to use the less bandwidth heavy ycbcr422 and ycbcr420 formats for a signal that
is less deceptible to interference.

In the future, automatic color calibration for screens might also depend on this
option being available.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_atomic_helper.c |  4 +++
 drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
 drivers/gpu/drm/drm_connector.c | 46 -
 include/drm/drm_connector.h | 17 +++
 4 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index bc3487964fb5..90d62f305257 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -687,6 +687,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->max_requested_bpc !=
new_connector_state->max_requested_bpc)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->preferred_color_format !=
+   new_connector_state->preferred_color_format)
+   new_crtc_state->connectors_changed = true;
}
 
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 438e9585b225..c536f5e22016 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -796,6 +796,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
   fence_ptr);
} else if (property == connector->max_bpc_property) {
state->max_requested_bpc = val;
+   } else if (property == connector->preferred_color_format_property) {
+   state->preferred_color_format = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -873,6 +875,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->preferred_color_format_property) {
+   *val = state->preferred_color_format;
} 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 b4aff7d6910f..1dc537514c71 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -889,6 +889,14 @@ static const struct drm_prop_enum_list 
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native,  "Native"}, /* DP */
 };
 
+static const struct drm_prop_enum_list drm_preferred_color_format_enum_list[] 
= {
+   { 0, "auto" },
+   { DRM_COLOR_FORMAT_RGB444, "rgb" },
+   { DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
+   { DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
+   { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
+};
+
 static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
{ 0, "unknown" },
{ DRM_COLOR_FORMAT_RGB444, "rgb" },
@@ -1219,11 +1227,19 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * Drivers shall use drm_connector_attach_active_bpc_property() to install
  * this property.
  *
+ * preferred color format:
+ * This property is used by userspace to change the used color format. When
+ * used the driver will use the selected format if valid for the hardware,
+ * sink, and current resolution and refresh rate combination. Drivers to
+ * use the function drm_connector_attach_preferred_color_format_property()
+ * to create and attach the property to the connector during
+ * initialization.
+ *
  * active color format:
  * This read-only property tells userspace the color format actually used
  * by the hardware display engine

[Intel-gfx] [PATCH v3 07/14] drm/amd/display: Add handling for new "active color format" property

2021-06-15 Thread Werner Sembach
This commit implements the "active color format" drm property for the AMD GPU
driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 28 +--
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +++
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f31bbcb11f03..b66336a1403e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6715,6 +6715,23 @@ static int convert_dc_color_depth_into_bpc (enum 
dc_color_depth display_color_de
return 0;
 }
 
+static int convert_dc_pixel_encoding_into_drm_color_format(enum 
dc_pixel_encoding display_pixel_encoding)
+{
+   switch (display_pixel_encoding) {
+   case PIXEL_ENCODING_RGB:
+   return DRM_COLOR_FORMAT_RGB444;
+   case PIXEL_ENCODING_YCBCR422:
+   return DRM_COLOR_FORMAT_YCRCB422;
+   case PIXEL_ENCODING_YCBCR444:
+   return DRM_COLOR_FORMAT_YCRCB444;
+   case PIXEL_ENCODING_YCBCR420:
+   return DRM_COLOR_FORMAT_YCRCB420;
+   default:
+   break;
+   }
+   return 0;
+}
+
 static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
  struct drm_crtc_state *crtc_state,
  struct drm_connector_state 
*conn_state)
@@ -7716,6 +7733,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   
drm_connector_attach_active_color_format_property(>base);
}
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
@@ -9091,13 +9109,19 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
if (crtc) {
new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
-   if (dm_new_crtc_state->stream)
+   if (dm_new_crtc_state->stream) {
drm_connector_set_active_bpc_property(connector,
convert_dc_color_depth_into_bpc(

dm_new_crtc_state->stream->timing.display_color_depth));
+   
drm_connector_set_active_color_format_property(connector,
+   
convert_dc_pixel_encoding_into_drm_color_format(
+   
dm_new_crtc_state->stream->timing.pixel_encoding));
+   }
}
-   else
+   else {
drm_connector_set_active_bpc_property(connector, 0);
+   
drm_connector_set_active_color_format_property(connector, 0);
+   }
}
 
/* Count number of newly disabled CRTCs for dropping PM refs later. */
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 0cf38743ec47..13151d13aa73 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -413,6 +413,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(>base, 8, 
16);
 
+   connector->active_color_format_property = 
master->base.active_color_format_property;
+   if (connector->active_color_format_property)
+   
drm_connector_attach_active_color_format_property(>base);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1

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


[Intel-gfx] [PATCH v3 05/14] drm/i915/display: Add handling for new "active bpc" property

2021-06-15 Thread Werner Sembach
This commit implements the "active bpc" drm property for the Intel GPU driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 14 ++
 drivers/gpu/drm/i915/display/intel_dp.c  |  8 ++--
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c|  4 +++-
 4 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 6be1b31af07b..ee3669bd4662 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10839,6 +10839,9 @@ static int intel_atomic_commit(struct drm_device *dev,
 {
struct intel_atomic_state *state = to_intel_atomic_state(_state);
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_connector *connector;
+   struct drm_connector_state *new_conn_state;
+   int i;
int ret = 0;
 
state->wakeref = intel_runtime_pm_get(_priv->runtime_pm);
@@ -10907,6 +10910,17 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
 
+   /* Extract information from crtc to communicate it to userspace as 
connector properties */
+   for_each_new_connector_in_state(>base, connector, 
new_conn_state, i) {
+   struct intel_crtc *crtc = to_intel_crtc(new_conn_state->crtc);
+   if (crtc) {
+   struct intel_crtc_state *new_crtc_state = 
intel_atomic_get_new_crtc_state(state, crtc);
+   drm_connector_set_active_bpc_property(connector, 
new_crtc_state->pipe_bpp / 3);
+   }
+   else
+   drm_connector_set_active_bpc_property(connector, 0);
+   }
+
drm_atomic_state_get(>base);
INIT_WORK(>base.commit_work, intel_atomic_commit_work);
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c983044..404a27e56ceb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4688,10 +4688,14 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
intel_attach_force_audio_property(connector);
 
intel_attach_broadcast_rgb_property(connector);
-   if (HAS_GMCH(dev_priv))
+   if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
-   else if (DISPLAY_VER(dev_priv) >= 5)
+   drm_connector_attach_active_bpc_property(connector, 6, 10);
+   }
+   else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_bpc_property(connector, 6, 12);
+   }
 
/* Register HDMI colorspace for case of lspcon */
if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index b170e272bdee..16bfc59570a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -851,6 +851,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->max_bpc_property)
drm_connector_attach_max_bpc_property(connector, 6, 12);
 
+   connector->active_bpc_property =
+   intel_dp->attached_connector->base.active_bpc_property;
+   if (connector->active_bpc_property)
+   drm_connector_attach_active_bpc_property(connector, 6, 12);
+
return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 7e51c98c475e..9160e21ac9d6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2513,8 +2513,10 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
if (DISPLAY_VER(dev_priv) >= 10)
drm_connector_attach_hdr_output_metadata_property(connector);
 
-   if (!HAS_GMCH(dev_priv))
+   if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
+   drm_connector_attach_active_bpc_property(connector, 8, 12);
+   }
 }
 
 /*
-- 
2.25.1

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


[Intel-gfx] [PATCH v3 11/14] drm/i915/display: Add handling for new "active color range" property

2021-06-15 Thread Werner Sembach
This commit implements the "active color range" drm property for the Intel GPU
driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 4 
 drivers/gpu/drm/i915/display/intel_dp.c  | 2 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c  | 5 +
 drivers/gpu/drm/i915/display/intel_hdmi.c| 1 +
 4 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 2cf09599ddc3..09d7c3da105a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10933,10 +10933,14 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_connector_set_active_bpc_property(connector, 
new_crtc_state->pipe_bpp / 3);

drm_connector_set_active_color_format_property(connector,

convert_intel_output_format_into_drm_color_format(new_crtc_state->output_format));
+   drm_connector_set_active_color_range_property(connector,
+   new_crtc_state->limited_color_range? 
DRM_MODE_COLOR_RANGE_LIMITED_16_235
+  : 
DRM_MODE_COLOR_RANGE_FULL);
}
else {
drm_connector_set_active_bpc_property(connector, 0);

drm_connector_set_active_color_format_property(connector, 0);
+   
drm_connector_set_active_color_range_property(connector, 
DRM_MODE_COLOR_RANGE_UNSET);
}
}
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 01fdb9141592..d648582d0786 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4692,11 +4692,13 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
drm_connector_attach_active_color_format_property(connector);
+   drm_connector_attach_active_color_range_property(connector);
}
else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
drm_connector_attach_active_color_format_property(connector);
+   drm_connector_attach_active_color_range_property(connector);
}
 
/* Register HDMI colorspace for case of lspcon */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 3e4237df3360..cb876175258f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -861,6 +861,11 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_color_format_property)
drm_connector_attach_active_color_format_property(connector);
 
+   connector->active_color_range_property =
+   intel_dp->attached_connector->base.active_color_range_property;
+   if (connector->active_color_range_property)
+   drm_connector_attach_active_color_range_property(connector);
+
return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 367aba57b55f..dacac23a6c30 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2517,6 +2517,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
drm_connector_attach_max_bpc_property(connector, 8, 12);
drm_connector_attach_active_bpc_property(connector, 8, 12);
drm_connector_attach_active_color_format_property(connector);
+   drm_connector_attach_active_color_range_property(connector);
}
 }
 
-- 
2.25.1

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


[Intel-gfx] [PATCH v3 03/14] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-15 Thread Werner Sembach
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 
---
 drivers/gpu/drm/drm_connector.c | 50 +
 include/drm/drm_connector.h |  8 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..02c310c1ac2d 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1197,6 +1197,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:
@@ -2152,6 +2160,48 @@ 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;
+
+   if (!connector->active_bpc_property) {
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
"active bpc", min, max);
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_bpc_property = prop;
+   drm_object_attach_property(>base, prop, 0);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
+
+/**
+ * drm_connector_set_active_bpc_property - sets the active bits per color 
property for a connector
+ * @connector: drm connector
+ * @active_bpc: bits per color for the connector currently active on "the 
cable"
+ *
+ * Should be used by atomic drivers to update the active bits per color over a 
connector.
+ */
+void drm_connector_set_active_bpc_property(struct drm_connector *connector, 
int active_bpc)
+{
+   drm_object_property_set_value(>base, 
connector->active_bpc_property, active_bpc);
+}
+EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach 
"HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 714d1a01c065..eee86de62a5f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1380,6 +1380,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)
@@ -1702,6 +1708,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);
+void drm_connector_set_active_bpc_property(struct drm_connector *connector, 
int active_bpc);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
2.25.1

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


[Intel-gfx] [PATCH v3 09/14] drm/uAPI: Add "active color range" drm property as feedback for userspace

2021-06-15 Thread Werner Sembach
Add a new general drm property "active color range" which can be used by graphic
drivers to report the used color range back to userspace.

There was no way to check which color range got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of the
monitor and what the default behaviour of the used driver is. This property
helps eliminating the guessing at this point.

In the future, automatic color calibration for screens might also depend on this
information being available.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_connector.c | 54 +
 include/drm/drm_connector.h | 26 
 2 files changed, 80 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2411b964c342..b4aff7d6910f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -897,6 +897,12 @@ static const struct drm_prop_enum_list 
drm_active_color_format_enum_list[] = {
{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
 };
 
+static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
+   { DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
+   { DRM_MODE_COLOR_RANGE_FULL, "Full" },
+   { DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
+};
+
 DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 drm_dp_subconnector_enum_list)
 
@@ -1221,6 +1227,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * drm_connector_attach_active_color_format_property() to install this
  * property.
  *
+ * active color range:
+ * This read-only property tells userspace the color range actually used by
+ * the hardware display engine on "the cable" on a connector. The chosen
+ * value depends on hardware capabilities of the monitor and the used color
+ * format. Drivers shall use
+ * drm_connector_attach_active_color_range_property() to install this
+ * property.
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -2258,6 +2272,46 @@ void 
drm_connector_set_active_color_format_property(struct drm_connector *connec
 }
 EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
 
+/**
+ * drm_connector_attach_active_color_range_property - attach "active color 
range" property
+ * @connector: connector to attach active color range property on.
+ *
+ * This is used to check the applied color range on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_range_property(struct drm_connector 
*connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   if (!connector->active_color_range_property) {
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, 
"active color range", drm_active_color_range_enum_list, 
ARRAY_SIZE(drm_active_color_range_enum_list));
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_color_range_property = prop;
+   drm_object_attach_property(>base, prop, 
DRM_MODE_COLOR_RANGE_UNSET);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_range_property);
+
+/**
+ * drm_connector_set_active_color_range_property - sets the active color range 
property for a connector
+ * @connector: drm connector
+ * @active_color_range: color range for the connector currently active on "the 
cable"
+ *
+ * Should be used by atomic drivers to update the active color range over a 
connector.
+ */
+void drm_connector_set_active_color_range_property(struct drm_connector 
*connector, enum drm_mode_color_range active_color_range)
+{
+   drm_object_property_set_value(>base, 
connector->active_color_range_property, active_color_range);
+}
+EXPORT_SYMBOL(drm_connector_set_active_color_range_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach 
"HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 99e4989dd6b3..5cb122812727 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -648,6 +648,24 @@ struct drm_tv_connector_state {
unsigned int hue;
 };
 
+/**
+ * enum drm_mode_color_range - color_range info for _connector
+ *
+ * This enum is used to represent full or limited color range on the display
+ * connector signal.
+ *
+ * @DRM_MODE_COLOR_RANGE_UNSET:Color range is 
unspecified/default.
+ * @DRM_MODE_COLOR_RANGE_FULL: Color range is full range, 0-255 for
+ * 8-Bit color depth.
+ * DRM_MODE_COLOR_RANGE_LIMITED_16_235:Color range is limited range, 
16-235 for
+ * 8-Bi

[Intel-gfx] [PATCH v3 06/14] drm/uAPI: Add "active color format" drm property as feedback for userspace

2021-06-15 Thread Werner Sembach
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.

There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of the
monitor, the GPU, and the connection used and what the default behaviour of the
used driver is (e.g. amdgpu prefers YCbCr 4:4:4 while i915 prefers RGB). This
property helps eliminating the guessing on this point.

In the future, automatic color calibration for screens might also depend on this
information being available.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_connector.c | 56 +
 include/drm/drm_connector.h |  8 +
 2 files changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 02c310c1ac2d..2411b964c342 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -889,6 +889,14 @@ static const struct drm_prop_enum_list 
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native,  "Native"}, /* DP */
 };
 
+static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
+   { 0, "unknown" },
+   { DRM_COLOR_FORMAT_RGB444, "rgb" },
+   { DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
+   { DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
+   { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
+};
+
 DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 drm_dp_subconnector_enum_list)
 
@@ -1205,6 +1213,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * Drivers shall use drm_connector_attach_active_bpc_property() to install
  * this property.
  *
+ * active color format:
+ * This read-only property tells userspace the color format 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. Drivers shall use
+ * drm_connector_attach_active_color_format_property() to install this
+ * property.
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -2202,6 +2218,46 @@ void drm_connector_set_active_bpc_property(struct 
drm_connector *connector, int
 }
 EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
 
+/**
+ * drm_connector_attach_active_color_format_property - attach "active color 
format" property
+ * @connector: connector to attach active color format property on.
+ *
+ * This is used to check the applied color format on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_format_property(struct drm_connector 
*connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   if (!connector->active_color_format_property) {
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, 
"active color format", drm_active_color_format_enum_list, 
ARRAY_SIZE(drm_active_color_format_enum_list));
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_color_format_property = prop;
+   drm_object_attach_property(>base, prop, 0);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_format_property);
+
+/**
+ * drm_connector_set_active_color_format_property - sets the active color 
format property for a connector
+ * @connector: drm connector
+ * @active_color_format: color format for the connector currently active on 
"the cable"
+ *
+ * Should be used by atomic drivers to update the active color format over a 
connector.
+ */
+void drm_connector_set_active_color_format_property(struct drm_connector 
*connector, u32 active_color_format)
+{
+   drm_object_property_set_value(>base, 
connector->active_color_format_property, active_color_format);
+}
+EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach 
"HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index eee86de62a5f..99e4989dd6b3 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1386,6 +1386,12 @@ struct drm_connector {
 */
struct drm_property *active_bpc_property;
 
+   /**
+* @active_color_format_property: Default connector property for the
+* active color format to be driven out of the connector.
+*/
+   struct drm_property *active_color_format_property;
+
 #define DRM_CONNECTOR_POLL_HPD (1 << 0)
 #define DRM_CONNECTOR_POLL_CONNECT (1 <&l

[Intel-gfx] [PATCH v3 04/14] drm/amd/display: Add handling for new "active bpc" property

2021-06-15 Thread Werner Sembach
This commit implements the "active bpc" drm property for the AMD GPU driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 ++-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index cd1df5cf4815..f31bbcb11f03 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7713,8 +7713,10 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
adev->mode_info.underscan_vborder_property,
0);
 
-   if (!aconnector->mst_port)
+   if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
+   drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   }
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
aconnector->base.state->max_bpc = (connector_type == 
DRM_MODE_CONNECTOR_eDP) ? 16 : 8;
@@ -9083,6 +9085,21 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
mutex_unlock(>dc_lock);
}
 
+   /* Extract information from crtc to communicate it to userspace as 
connector properties */
+   for_each_new_connector_in_state(state, connector, new_con_state, i) {
+   struct drm_crtc *crtc = new_con_state->crtc;
+   if (crtc) {
+   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
+   dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+   if (dm_new_crtc_state->stream)
+   drm_connector_set_active_bpc_property(connector,
+   convert_dc_color_depth_into_bpc(
+   
dm_new_crtc_state->stream->timing.display_color_depth));
+   }
+   else
+   drm_connector_set_active_bpc_property(connector, 0);
+   }
+
/* Count number of newly disabled CRTCs for dropping PM refs later. */
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
  new_crtc_state, i) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 5568d4e518e6..0cf38743ec47 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -409,6 +409,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
if (connector->max_bpc_property)
drm_connector_attach_max_bpc_property(connector, 8, 16);
 
+   connector->active_bpc_property = master->base.active_bpc_property;
+   if (connector->active_bpc_property)
+   drm_connector_attach_active_bpc_property(>base, 8, 
16);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1

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


[Intel-gfx] [PATCH v3 01/14] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check

2021-06-15 Thread Werner Sembach
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.

Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI, there is
no reason to use RGB when the display reports drm_mode_is_420_only() even on a
non HDMI connection.

This patch also moves both checks in the same if-case. This  eliminates an extra
else-if-case.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6fda0dfb78f8..44757720b15f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5353,10 +5353,7 @@ static void fill_stream_properties_from_drm_display_mode(
timing_out->v_border_bottom = 0;
/* TODO: un-hardcode */
if (drm_mode_is_420_only(info, mode_in)
-   && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
-   timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
-   else if (drm_mode_is_420_also(info, mode_in)
-   && aconnector->force_yuv420_output)
+   || (drm_mode_is_420_also(info, mode_in) && 
aconnector->force_yuv420_output))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
else if ((connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCRCB444)
&& stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
-- 
2.25.1

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


[Intel-gfx] [PATCH v3 02/14] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc

2021-06-15 Thread Werner Sembach
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 44757720b15f..cd1df5cf4815 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6705,6 +6705,10 @@ static int convert_dc_color_depth_into_bpc (enum 
dc_color_depth display_color_de
return 14;
case COLOR_DEPTH_161616:
return 16;
+   case COLOR_DEPTH_999:
+   return 9;
+   case COLOR_DEPTH_11:
+   return 11;
default:
break;
}
-- 
2.25.1

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


[Intel-gfx] [PATCH v3 00/14] New uAPI drm properties for color management

2021-06-15 Thread Werner Sembach
I started work on my proposal for better color handling in Linux display
drivers: https://lkml.org/lkml/2021/5/12/764

In this 3rd revision everything except the generalised Broadcast RGB
implementation is included. I did however not yet include everything suggested
in the feedback for v1 and v2.

I rebased the patch series on drm-tip to have the latest changes in i915's
YCbCr420 handling and to make the intel-gfx ci not fail on merge anymore.

The read only properties are now correctly marked as immutable.

Some questions I already have:

I think Broadcast RGB is really no good name for the property as, at least in
theory, YCbCr can also be "Limited" or "Full". Should the new implementation
have a different name and make "Broadcast RGB" an alias for it? I propose
"preferred color range" as the new name.

I have not tested dp mst (both on AMD and Intel) as i have no adapter for it at
hand. If one can test it, please let me know if things break or not.

I found the DRM_MODE_PROP_ATOMIC flag and from the documentation it sounds like
"max bpc" (and "preferred color format" and "Broadcast RGB") should have it. Is
there a reason it doesn't?

I have not yet looked into dsc and dithering behaviour.

I have already submitted the first two patches separately to the lkml as they 
fix
potential bugs and don't introduce new uAPI.

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


[Intel-gfx] [PATCH v2 7/7] drm/i915/display: Add handling for new "active color format" property

2021-06-08 Thread Werner Sembach
This commit implements the "active color format" drm property for the Intel GPU
driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 20 +++-
 drivers/gpu/drm/i915/display/intel_dp.c  |  2 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  1 +
 drivers/gpu/drm/i915/display/intel_hdmi.c|  1 +
 4 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 50c11b8770a7..e3e98c959cb4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10158,6 +10158,21 @@ static void 
intel_atomic_prepare_plane_clear_colors(struct intel_atomic_state *s
}
 }
 
+static int convert_intel_output_format_into_drm_color_format(enum 
intel_output_format output_format)
+{
+   switch (output_format) {
+   case INTEL_OUTPUT_FORMAT_RGB:
+   return DRM_COLOR_FORMAT_RGB444;
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   return DRM_COLOR_FORMAT_YCRCB420;
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   return DRM_COLOR_FORMAT_YCRCB444;
+   default:
+   break;
+   }
+   return 0;
+}
+
 static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 {
struct drm_device *dev = state->base.dev;
@@ -10465,9 +10480,12 @@ static int intel_atomic_commit(struct drm_device *dev,
if (crtc) {
struct intel_crtc_state *new_crtc_state = 
intel_atomic_get_new_crtc_state(state, crtc);
new_conn_state->active_bpc = new_crtc_state->pipe_bpp / 
3;
+   new_conn_state->active_color_format = 
convert_intel_output_format_into_drm_color_format(new_crtc_state->output_format);
}
-   else
+   else {
new_conn_state->active_bpc = 0;
+   new_conn_state->active_color_format = 0;
+   }
}
 
drm_atomic_state_get(>base);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 67826ba976ed..7d58bc7972d0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4674,10 +4674,12 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
+   drm_connector_attach_active_color_format_property(connector);
}
else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_color_format_property(connector);
}
 
/* Register HDMI colorspace for case of lspcon */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 5a1869dc2210..9143adccb5d0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -847,6 +847,7 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->max_bpc_property) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_color_format_property(connector);
}
 
return connector;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 8af78b27b6ce..0b57d924987e 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2466,6 +2466,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
drm_connector_attach_active_bpc_property(connector, 8, 12);
+   drm_connector_attach_active_color_format_property(connector);
}
 }
 
-- 
2.25.1

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


[Intel-gfx] [PATCH v2 6/7] drm/amd/display: Add handling for new "active color format" property

2021-06-08 Thread Werner Sembach
This commit implements the "active color format" drm property for the AMD GPU
driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 27 +--
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  1 +
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e57b2b743d36..019be46def1d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6525,6 +6525,23 @@ static int convert_dc_color_depth_into_bpc (enum 
dc_color_depth display_color_de
return 0;
 }
 
+static int convert_dc_pixel_encoding_into_drm_color_format(enum 
dc_pixel_encoding display_pixel_encoding)
+{
+   switch (display_pixel_encoding) {
+   case PIXEL_ENCODING_RGB:
+   return DRM_COLOR_FORMAT_RGB444;
+   case PIXEL_ENCODING_YCBCR422:
+   return DRM_COLOR_FORMAT_YCRCB422;
+   case PIXEL_ENCODING_YCBCR444:
+   return DRM_COLOR_FORMAT_YCRCB444;
+   case PIXEL_ENCODING_YCBCR420:
+   return DRM_COLOR_FORMAT_YCRCB420;
+   default:
+   break;
+   }
+   return 0;
+}
+
 static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
  struct drm_crtc_state *crtc_state,
  struct drm_connector_state 
*conn_state)
@@ -7522,6 +7539,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   
drm_connector_attach_active_color_format_property(>base);
}
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
@@ -8898,12 +8916,17 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
if (crtc) {
new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
-   if (dm_new_crtc_state->stream)
+   if (dm_new_crtc_state->stream) {
new_con_state->active_bpc = 
convert_dc_color_depth_into_bpc(

dm_new_crtc_state->stream->timing.display_color_depth);
+   new_con_state->active_color_format = 
convert_dc_pixel_encoding_into_drm_color_format(
+   
dm_new_crtc_state->stream->timing.pixel_encoding);
+   }
}
-   else
+   else {
new_con_state->active_bpc = 0;
+   new_con_state->active_color_format = 0;
+   }
}
 
/* Count number of newly disabled CRTCs for dropping PM refs later. */
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 2a8dc6b2c6c7..f68950da9ff8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -400,6 +400,7 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
if (connector->max_bpc_property) {
drm_connector_attach_max_bpc_property(connector, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   
drm_connector_attach_active_color_format_property(>base);
}
 
connector->vrr_capable_property = master->base.vrr_capable_property;
-- 
2.25.1

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


[Intel-gfx] [PATCH v2 2/7] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-08 Thread Werner Sembach
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 
---
 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.
+ *
  * 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(>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 &l

[Intel-gfx] [PATCH v2 3/7] drm/amd/display: Add handling for new "active bpc" property

2021-06-08 Thread Werner Sembach
This commit implements the "active bpc" drm property for the AMD GPU driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 18 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c|  4 +++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index dbbccbed7b20..e57b2b743d36 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7519,8 +7519,10 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
adev->mode_info.underscan_vborder_property,
0);
 
-   if (!aconnector->mst_port)
+   if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
+   drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   }
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
aconnector->base.state->max_bpc = (connector_type == 
DRM_MODE_CONNECTOR_eDP) ? 16 : 8;
@@ -8890,6 +8892,20 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
mutex_unlock(>dc_lock);
}
 
+   /* Extract information from crtc to communicate it to userspace as 
connector properties */
+   for_each_new_connector_in_state(state, connector, new_con_state, i) {
+   struct drm_crtc *crtc = new_con_state->crtc;
+   if (crtc) {
+   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
+   dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+   if (dm_new_crtc_state->stream)
+   new_con_state->active_bpc = 
convert_dc_color_depth_into_bpc(
+   
dm_new_crtc_state->stream->timing.display_color_depth);
+   }
+   else
+   new_con_state->active_bpc = 0;
+   }
+
/* Count number of newly disabled CRTCs for dropping PM refs later. */
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
  new_crtc_state, i) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9b221db526dc..2a8dc6b2c6c7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -397,8 +397,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
}
 
connector->max_bpc_property = master->base.max_bpc_property;
-   if (connector->max_bpc_property)
+   if (connector->max_bpc_property) {
drm_connector_attach_max_bpc_property(connector, 8, 16);
+   drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   }
 
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
-- 
2.25.1

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


[Intel-gfx] [PATCH v2 5/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

2021-06-08 Thread Werner Sembach
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.

There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of the
monitor, the GPU, and the connection used and what the default behaviour of the
used driver is (e.g. amdgpu prefers YCbCr 4:4:4 while i915 prefers RGB). This
property helps eliminating the guessing on this point.

In the future, automatic color calibration for screens might also depend on this
information being available.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_atomic_uapi.c |  2 ++
 drivers/gpu/drm/drm_connector.c   | 46 +++
 include/drm/drm_connector.h   | 13 +
 3 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 7ae4e40936b5..bb78da2405f9 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -875,6 +875,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->max_requested_bpc;
} else if (property == connector->active_bpc_property) {
*val = state->active_bpc;
+   } else if (property == connector->active_color_format_property) {
+   *val = state->active_color_format;
} 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 c0c3c09bfed0..f4f35c4117b6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -887,6 +887,14 @@ static const struct drm_prop_enum_list 
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native,  "Native"}, /* DP */
 };
 
+static const struct drm_prop_enum_list drm_color_format_enum_list[] = {
+   { 0, "none" },
+   { DRM_COLOR_FORMAT_RGB444, "rgb" },
+   { DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
+   { DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
+   { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
+};
+
 DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 drm_dp_subconnector_enum_list)
 
@@ -1202,6 +1210,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * display engine and connected monitor, and the "max bpc" property.
  * Drivers shall use drm_connector_attach_active_bpc_property() to install
  * this property.
+
+ * active color format:
+ * This read-only property tells userspace the color format 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. Drivers shall use
+ * drm_connector_attach_active_color_format_property() to install this
+ * property.
  *
  * Connectors also have one standardized atomic property:
  *
@@ -2191,6 +2207,36 @@ int drm_connector_attach_active_bpc_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
 
+/**
+ * drm_connector_attach_active_color_format_property - attach "active color 
format" property
+ * @connector: connector to attach active color format property on.
+ *
+ * This is used to check the applied color format on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_format_property(struct drm_connector 
*connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   prop = connector->active_color_format_property;
+   if (!prop) {
+   prop = drm_property_create_enum(dev, 0, "active color format", 
drm_color_format_enum_list, ARRAY_SIZE(drm_color_format_enum_list));
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_color_format_property = prop;
+   }
+
+   drm_object_attach_property(>base, prop, 0);
+   connector->state->active_color_format = 0;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_format_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 c58cba2b6afe..167cd36129ae 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -788,6 +788,12 @@ struct drm_connector_state {
 */
u8 active_bpc;
 
+   /**
+* active_color_format: Read only property set by the GPU driver to the
+* actually used color format

[Intel-gfx] [PATCH v2 1/7] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc

2021-06-08 Thread Werner Sembach
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 652cc1a0e450..dbbccbed7b20 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6515,6 +6515,10 @@ static int convert_dc_color_depth_into_bpc (enum 
dc_color_depth display_color_de
return 14;
case COLOR_DEPTH_161616:
return 16;
+   case COLOR_DEPTH_999:
+   return 9;
+   case COLOR_DEPTH_11:
+   return 11;
default:
break;
}
-- 
2.25.1

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


[Intel-gfx] [PATCH v2 4/7] drm/i915/display: Add handling for new "active bpc" property

2021-06-08 Thread Werner Sembach
This commits implements the "active bpc" drm property for the Intel GPU driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 14 ++
 drivers/gpu/drm/i915/display/intel_dp.c  |  8 ++--
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  4 +++-
 drivers/gpu/drm/i915/display/intel_hdmi.c|  4 +++-
 4 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 64e9107d70f7..50c11b8770a7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10388,6 +10388,9 @@ static int intel_atomic_commit(struct drm_device *dev,
 {
struct intel_atomic_state *state = to_intel_atomic_state(_state);
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_connector *connector;
+   struct drm_connector_state *new_conn_state;
+   int i;
int ret = 0;
 
state->wakeref = intel_runtime_pm_get(_priv->runtime_pm);
@@ -10456,6 +10459,17 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
 
+   /* Extract information from crtc to communicate it to userspace as 
connector properties */
+   for_each_new_connector_in_state(>base, connector, 
new_conn_state, i) {
+   struct intel_crtc *crtc = to_intel_crtc(new_conn_state->crtc);
+   if (crtc) {
+   struct intel_crtc_state *new_crtc_state = 
intel_atomic_get_new_crtc_state(state, crtc);
+   new_conn_state->active_bpc = new_crtc_state->pipe_bpp / 
3;
+   }
+   else
+   new_conn_state->active_bpc = 0;
+   }
+
drm_atomic_state_get(>base);
INIT_WORK(>base.commit_work, intel_atomic_commit_work);
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 642c60f3d9b1..67826ba976ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4671,10 +4671,14 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
intel_attach_force_audio_property(connector);
 
intel_attach_broadcast_rgb_property(connector);
-   if (HAS_GMCH(dev_priv))
+   if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
-   else if (DISPLAY_VER(dev_priv) >= 5)
+   drm_connector_attach_active_bpc_property(connector, 6, 10);
+   }
+   else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_bpc_property(connector, 6, 12);
+   }
 
/* Register HDMI colorspace for case of lspcon */
if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 2daa3f67791e..5a1869dc2210 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -844,8 +844,10 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
 */
connector->max_bpc_property =
intel_dp->attached_connector->base.max_bpc_property;
-   if (connector->max_bpc_property)
+   if (connector->max_bpc_property) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_bpc_property(connector, 6, 12);
+   }
 
return connector;
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index d69f0a6dc26d..8af78b27b6ce 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2463,8 +2463,10 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
drm_object_attach_property(>base,

connector->dev->mode_config.hdr_output_metadata_property, 0);
 
-   if (!HAS_GMCH(dev_priv))
+   if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
+   drm_connector_attach_active_bpc_property(connector, 8, 12);
+   }
 }
 
 /*
-- 
2.25.1

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


[Intel-gfx] [PATCH 0/7] Add "activ bpc" and "active color format" drm property

2021-06-08 Thread Werner Sembach
I started work on my proposal for better color handling in Linux display
drivers: https://lkml.org/lkml/2021/5/12/764

In this 2nd revision the first two read-only properties are now implemented for
amdgpu and i915. I post it here to collect collect some additional feedback, if
someone sees an improvement opportunity.

I have already commited the first patch in this series independently as it fixes
a function already in use.

Some of the feedback from the first post is already implemented.

The actual update of the values is implemented in patch three and four and six
and seven in the atomic_commit_tail() function of amdgpu and atomic_commit()
function of i915 respectively. They do get updated more often than needed with
the current approach, but without harm since just the same value is written
again. A check if the update is required would be the same amount of
computation.


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


Re: [Intel-gfx] [PATCH 4/4] drm/i915/display: Add handling for new "active bpc" property

2021-06-08 Thread Werner Sembach


Am 07.06.21 um 22:33 schrieb Werner Sembach:

Am 07.06.21 um 08:47 schrieb Werner Sembach:


Am 04.06.21 um 19:30 schrieb Ville Syrjälä:

On Fri, Jun 04, 2021 at 07:17:23PM +0200, Werner Sembach wrote:
This commits implements the "active bpc" drm property for the Intel 
GPU driver.


Signed-off-by: Werner Sembach 
---
  drivers/gpu/drm/i915/display/intel_display.c | 13 +
  drivers/gpu/drm/i915/display/intel_dp.c  |  8 ++--
  drivers/gpu/drm/i915/display/intel_dp_mst.c  |  4 +++-
  drivers/gpu/drm/i915/display/intel_hdmi.c    |  4 +++-
  4 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c

index 64e9107d70f7..f7898d9d7438 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10164,6 +10164,8 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)

  struct drm_i915_private *dev_priv = to_i915(dev);
  struct intel_crtc_state *new_crtc_state, *old_crtc_state;
  struct intel_crtc *crtc;
+    struct drm_connector *connector;
+    struct drm_connector_state *new_conn_state;
  u64 put_domains[I915_MAX_PIPES] = {};
  intel_wakeref_t wakeref = 0;
  int i;
@@ -10324,6 +10326,17 @@ static void 
intel_atomic_commit_tail(struct intel_atomic_state *state)

  }
  intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
  +    /* Extract information from crtc to communicate it to 
userspace as connector properties */
+    for_each_new_connector_in_state(>base, connector, 
new_conn_state, i) {

+    struct drm_crtc *crtc = new_conn_state->crtc;
+    if (crtc) {
+    new_crtc_state = 
to_intel_crtc_state(drm_atomic_get_new_crtc_state(>base, 
crtc));

intel_atomic_get_new_crtc_state()

Thanks, will use that.



+ new_conn_state->active_bpc = new_crtc_state->pipe_bpp / 3;
+    }
+    else
+    new_conn_state->active_bpc = 0;
+    }

This also seems too late. I think the whole thing should be
done somewhere around the normal swap_state() stuff.

Ok, will look into it.
So I tried to put it in intel_atomic_commit() after 
drm_atomic_helper_swap_state() and before 
INIT_WORK(>base.commit_work, intel_atomic_commit_work) (which 
creates a worker for intel_atomic_commit_tail), but somewhere in 
between, the connector_state seems to change: The bpc written with the 
for_each_new_connector_in_state() loop, gets discarded.


This was not the problem. Setting the drm property immutable made it 
(also?) immutable from the driver context, which I didn't test separately.


Removed the immutable again and moved the loop.




+
  /*
   * Defer the cleanup of the old state to a separate worker to 
not
   * impede the current task (userspace for blocking modesets) 
that
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c

index 642c60f3d9b1..67826ba976ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4671,10 +4671,14 @@ intel_dp_add_properties(struct intel_dp 
*intel_dp, struct drm_connector *connect

  intel_attach_force_audio_property(connector);
    intel_attach_broadcast_rgb_property(connector);
-    if (HAS_GMCH(dev_priv))
+    if (HAS_GMCH(dev_priv)) {
  drm_connector_attach_max_bpc_property(connector, 6, 10);
-    else if (DISPLAY_VER(dev_priv) >= 5)
+    drm_connector_attach_active_bpc_property(connector, 6, 10);
+    }
+    else if (DISPLAY_VER(dev_priv) >= 5) {
  drm_connector_attach_max_bpc_property(connector, 6, 12);
+    drm_connector_attach_active_bpc_property(connector, 6, 12);
+    }
    /* Register HDMI colorspace for case of lspcon */
  if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c

index 2daa3f67791e..5a1869dc2210 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -844,8 +844,10 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo

   */
  connector->max_bpc_property =
intel_dp->attached_connector->base.max_bpc_property;
-    if (connector->max_bpc_property)
+    if (connector->max_bpc_property) {
  drm_connector_attach_max_bpc_property(connector, 6, 12);
+    drm_connector_attach_active_bpc_property(connector, 6, 12);
+    }
    return connector;
  diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c

index d69f0a6dc26d..8af78b27b6ce 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2463,8 +2463,10 @@ intel_hdmi_add_properties(struct intel_hdmi 
*intel_hdmi, struct drm_connector *c

drm_object_attach_property(>base

Re: [Intel-gfx] [PATCH 4/4] drm/i915/display: Add handling for new "active bpc" property

2021-06-07 Thread Werner Sembach

Am 07.06.21 um 08:47 schrieb Werner Sembach:


Am 04.06.21 um 19:30 schrieb Ville Syrjälä:

On Fri, Jun 04, 2021 at 07:17:23PM +0200, Werner Sembach wrote:
This commits implements the "active bpc" drm property for the Intel 
GPU driver.


Signed-off-by: Werner Sembach 
---
  drivers/gpu/drm/i915/display/intel_display.c | 13 +
  drivers/gpu/drm/i915/display/intel_dp.c  |  8 ++--
  drivers/gpu/drm/i915/display/intel_dp_mst.c  |  4 +++-
  drivers/gpu/drm/i915/display/intel_hdmi.c    |  4 +++-
  4 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c

index 64e9107d70f7..f7898d9d7438 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10164,6 +10164,8 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)

  struct drm_i915_private *dev_priv = to_i915(dev);
  struct intel_crtc_state *new_crtc_state, *old_crtc_state;
  struct intel_crtc *crtc;
+    struct drm_connector *connector;
+    struct drm_connector_state *new_conn_state;
  u64 put_domains[I915_MAX_PIPES] = {};
  intel_wakeref_t wakeref = 0;
  int i;
@@ -10324,6 +10326,17 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)

  }
  intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
  +    /* Extract information from crtc to communicate it to 
userspace as connector properties */
+    for_each_new_connector_in_state(>base, connector, 
new_conn_state, i) {

+    struct drm_crtc *crtc = new_conn_state->crtc;
+    if (crtc) {
+    new_crtc_state = 
to_intel_crtc_state(drm_atomic_get_new_crtc_state(>base, crtc));

intel_atomic_get_new_crtc_state()

Thanks, will use that.



+ new_conn_state->active_bpc = new_crtc_state->pipe_bpp / 3;
+    }
+    else
+    new_conn_state->active_bpc = 0;
+    }

This also seems too late. I think the whole thing should be
done somewhere around the normal swap_state() stuff.

Ok, will look into it.
So I tried to put it in intel_atomic_commit() after 
drm_atomic_helper_swap_state() and before 
INIT_WORK(>base.commit_work, intel_atomic_commit_work) (which 
creates a worker for intel_atomic_commit_tail), but somewhere in 
between, the connector_state seems to change: The bpc written with the 
for_each_new_connector_in_state() loop, gets discarded.



+
  /*
   * Defer the cleanup of the old state to a separate worker to not
   * impede the current task (userspace for blocking modesets) that
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c

index 642c60f3d9b1..67826ba976ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4671,10 +4671,14 @@ intel_dp_add_properties(struct intel_dp 
*intel_dp, struct drm_connector *connect

  intel_attach_force_audio_property(connector);
    intel_attach_broadcast_rgb_property(connector);
-    if (HAS_GMCH(dev_priv))
+    if (HAS_GMCH(dev_priv)) {
  drm_connector_attach_max_bpc_property(connector, 6, 10);
-    else if (DISPLAY_VER(dev_priv) >= 5)
+    drm_connector_attach_active_bpc_property(connector, 6, 10);
+    }
+    else if (DISPLAY_VER(dev_priv) >= 5) {
  drm_connector_attach_max_bpc_property(connector, 6, 12);
+    drm_connector_attach_active_bpc_property(connector, 6, 12);
+    }
    /* Register HDMI colorspace for case of lspcon */
  if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c

index 2daa3f67791e..5a1869dc2210 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -844,8 +844,10 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo

   */
  connector->max_bpc_property =
intel_dp->attached_connector->base.max_bpc_property;
-    if (connector->max_bpc_property)
+    if (connector->max_bpc_property) {
  drm_connector_attach_max_bpc_property(connector, 6, 12);
+    drm_connector_attach_active_bpc_property(connector, 6, 12);
+    }
    return connector;
  diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c

index d69f0a6dc26d..8af78b27b6ce 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2463,8 +2463,10 @@ intel_hdmi_add_properties(struct intel_hdmi 
*intel_hdmi, struct drm_connector *c

  drm_object_attach_property(>base,
connector->dev->mode_config.hdr_output_metadata_property, 0);
  -    if (!HAS_GMCH(dev_priv))
+    if (!HAS_GMCH(dev_priv)) {
  drm_connector_attach_max_bpc_property(connector, 8, 12);
+    drm_connector_attach

Re: [Intel-gfx] [PATCH 2/4] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-07 Thread Werner Sembach


Am 07.06.21 um 09:52 schrieb Pekka Paalanen:

On Fri,  4 Jun 2021 19:17:21 +0200
Werner Sembach  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 available.

Signed-off-by: Werner Sembach 
---
  drivers/gpu/drm/drm_atomic_uapi.c |  2 ++
  drivers/gpu/drm/drm_connector.c   | 40 +++
  include/drm/drm_connector.h   | 15 
  3 files changed, 57 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..5f42a5be5822 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1195,6 +1195,13 @@ 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 is used by userspace check the bit depth
+ * actually applied by the GPU driver after evaluation all hardware
+ * capabilities and max bpc. Drivers to use the function
+ * drm_connector_attach_active_bpc_property() to create and attach the
+ * property to the connector during initialization.
+ *

Hi Werner,

the idea looks good to me, but the above doc could be a little more
fluent. May I suggest something like:

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.

There should also be something said about dithering done by the display
engine (not monitor), but I'm not sure how that should be worded. It
may also depend on if and how userspace can know about dithering. So if
a dithering related property is added later, maybe add a note here too
in that patch.
For this, and the DSC that Ville Syrjälä mentioned, I guess "the same 
behavior as max bpc" would be the most intuitive. But I don't know what 
that is and it's also not mentioned in the documentation.



Thanks,
pq



   * Connectors also have one standardized atomic property:
   *
   * CRTC_ID:
@@ -2150,6 +2157,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(>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 va

Re: [Intel-gfx] [PATCH 2/4] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-07 Thread Werner Sembach



Am 07.06.21 um 09:40 schrieb Maxime Ripard:

Hi,

On Fri, Jun 04, 2021 at 07:17:21PM +0200, Werner Sembach 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.

Just a heads up, we'll need an open source project that has accepted it
before merging it.

See 
https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#open-source-userspace-requirements

Yes, I know.



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

Signed-off-by: Werner Sembach 
---
  drivers/gpu/drm/drm_atomic_uapi.c |  2 ++
  drivers/gpu/drm/drm_connector.c   | 40 +++
  include/drm/drm_connector.h   | 15 
  3 files changed, 57 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..5f42a5be5822 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1195,6 +1195,13 @@ 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 is used by userspace check the bit depth
+ * actually applied by the GPU driver after evaluation all hardware

 ^ display

Depending on the system, the display component might have a GPU attached
or not, and the GPU might have a display component or not.

Ok, I try to bee more clear in the wording



+ * capabilities and max bpc. Drivers to use the function
+ * drm_connector_attach_active_bpc_property() to create and attach the
+ * property to the connector during initialization.
+ *
   * Connectors also have one standardized atomic property:
   *
   * CRTC_ID:
@@ -2150,6 +2157,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(>base, prop, 0);
+   connector->state->active_bpc = 0;

I guess we want to default to 8?

Maxime
The default state should only be active when no display is connected or 
the display is off, so I thought 0 makes more sense, as no active 
display = no active bpc.

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


  1   2   >