All of lore.kernel.org
 help / color / mirror / Atom feed
From: Werner Sembach <wse@tuxedocomputers.com>
To: harry.wentland@amd.com, sunpeng.li@amd.com,
	alexander.deucher@amd.com, christian.koenig@amd.com,
	airlied@linux.ie, daniel@ffwll.ch,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	tzimmermann@suse.de, jani.nikula@linux.intel.com,
	joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org
Subject: [PATCH v3 00/14] New uAPI drm properties for color management
Date: Tue, 15 Jun 2021 16:14:11 +0200	[thread overview]
Message-ID: <20210615141426.6001-1-wse@tuxedocomputers.com> (raw)

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.


WARNING: multiple messages have this Message-ID (diff)
From: Werner Sembach <wse@tuxedocomputers.com>
To: harry.wentland@amd.com, sunpeng.li@amd.com,
	alexander.deucher@amd.com, christian.koenig@amd.com,
	airlied@linux.ie, daniel@ffwll.ch,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	tzimmermann@suse.de, jani.nikula@linux.intel.com,
	joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v3 00/14] New uAPI drm properties for color management
Date: Tue, 15 Jun 2021 16:14:11 +0200	[thread overview]
Message-ID: <20210615141426.6001-1-wse@tuxedocomputers.com> (raw)

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

WARNING: multiple messages have this Message-ID (diff)
From: Werner Sembach <wse@tuxedocomputers.com>
To: harry.wentland@amd.com, sunpeng.li@amd.com,
	alexander.deucher@amd.com, christian.koenig@amd.com,
	airlied@linux.ie, daniel@ffwll.ch,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	tzimmermann@suse.de, jani.nikula@linux.intel.com,
	joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org
Subject: [PATCH v3 00/14] New uAPI drm properties for color management
Date: Tue, 15 Jun 2021 16:14:11 +0200	[thread overview]
Message-ID: <20210615141426.6001-1-wse@tuxedocomputers.com> (raw)

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.

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

             reply	other threads:[~2021-06-15 14:15 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-15 14:14 Werner Sembach [this message]
2021-06-15 14:14 ` [PATCH v3 00/14] New uAPI drm properties for color management Werner Sembach
2021-06-15 14:14 ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 01/14] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 02/14] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 03/14] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 17:33   ` Werner Sembach
2021-06-15 17:33     ` Werner Sembach
2021-06-15 17:33     ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 04/14] drm/amd/display: Add handling for new "active bpc" property Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 05/14] drm/i915/display: " Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 06/14] drm/uAPI: Add "active color format" drm property as feedback for userspace Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 07/14] drm/amd/display: Add handling for new "active color format" property Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 08/14] drm/i915/display: " Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 09/14] drm/uAPI: Add "active color range" drm property as feedback for userspace Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 10/14] drm/amd/display: Add handling for new "active color range" property Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 11/14] drm/i915/display: " Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 12/14] drm/uAPI: Add "preferred color format" drm property as setting for userspace Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 13/14] drm/amd/display: Add handling for new "preferred color format" property Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:14 ` [PATCH v3 14/14] drm/i915/display: " Werner Sembach
2021-06-15 14:14   ` Werner Sembach
2021-06-15 14:14   ` [Intel-gfx] " Werner Sembach
2021-06-15 14:46 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for New uAPI drm properties for color management Patchwork
2021-06-15 14:48 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-06-15 15:21 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-06-15 23:28 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210615141426.6001-1-wse@tuxedocomputers.com \
    --to=wse@tuxedocomputers.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=sunpeng.li@amd.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.