[PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

[PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

[Robert Mader]

The client cap is currently advertised unconditionally, even for drivers
that do not support plane color pipelines. If clients supporting the later,
like Wayland compositors or tools like drm_info, enable the client cap on
such drivers they will be left without both color pipeline and the legacy
properties COLOR_ENCODING and COLOR_RANGE, effectively breaking YUV->RGB
conversion support.

Prevent that by only marking the cap supported if there are actually planes
with color pipelines.

Note: while the color pipeline replacement for the legacy properties is
still under review (1), we can assume that it will work as a drop-in
replacement. That means any plane on any hardware currently supporting
the legacy properties will be able to offer a functionally equal color
pipeline and there will be no technical reason keep using the legacy
properties if both the driver and the client support the new API.

1: https://lore.kernel.org/dri-devel/20260623164812.81110-1-harry.wentland@amd.com/

Signed-off-by: Robert Mader <robert.mader@collabora.com>

---

Changes in v3:
 - Move the new check behind the existing EINVAL ones
 - Rebase on latest drm-misc-next

Changes in v2:
 - Replace the driver feature with a simple check (suggested by Maarten
   Lankhorst <maarten.lankhorst@linux.intel.com>)
 - Expand the commit message slightly and change the title
---
 drivers/gpu/drm/drm_ioctl.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index e2df4becce62..9039a39c4324 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -373,13 +373,25 @@ drm_setclientcap(struct drm_device *dev, void *data, struct drm_file *file_priv)
 			return -EINVAL;
 		file_priv->supports_virtualized_cursor_plane = req->value;
 		break;
-	case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE:
+	case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE: {
+		struct drm_plane *plane;
+		bool has_plane_with_color_pipeline = false;
+
 		if (!file_priv->atomic)
 			return -EINVAL;
 		if (req->value > 1)
 			return -EINVAL;
+		drm_for_each_plane(plane, dev) {
+			if (plane->color_pipeline_property) {
+				has_plane_with_color_pipeline = true;
+				break;
+			}
+		}
+		if (!has_plane_with_color_pipeline)
+			return -EOPNOTSUPP;
 		file_priv->plane_color_pipeline = req->value;
 		break;
+	}
 	default:
 		return -EINVAL;
 	}
-- 
2.55.0

Re: [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

[Melissa Wen]

On 03/07/2026 09:32, Robert Mader wrote:
> The client cap is currently advertised unconditionally, even for drivers
> that do not support plane color pipelines. If clients supporting the later,
> like Wayland compositors or tools like drm_info, enable the client cap on
> such drivers they will be left without both color pipeline and the legacy
> properties COLOR_ENCODING and COLOR_RANGE, effectively breaking YUV->RGB
> conversion support.
>
> Prevent that by only marking the cap supported if there are actually planes
> with color pipelines.

Hi Robert,

I think Maarten probably wants to take one last look.

But just to add that this approach looks good to me. Thanks for working 
on it.

Reviewed-by: Melissa Wen <mwen@igalia.com>

>
> Note: while the color pipeline replacement for the legacy properties is
> still under review (1), we can assume that it will work as a drop-in
> replacement. That means any plane on any hardware currently supporting
> the legacy properties will be able to offer a functionally equal color
> pipeline and there will be no technical reason keep using the legacy
> properties if both the driver and the client support the new API.
>
> 1: https://lore.kernel.org/dri-devel/20260623164812.81110-1-harry.wentland@amd.com/
>
> Signed-off-by: Robert Mader <robert.mader@collabora.com>
>
> ---
>
> Changes in v3:
>   - Move the new check behind the existing EINVAL ones
>   - Rebase on latest drm-misc-next
>
> Changes in v2:
>   - Replace the driver feature with a simple check (suggested by Maarten
>     Lankhorst <maarten.lankhorst@linux.intel.com>)
>   - Expand the commit message slightly and change the title
> ---
>   drivers/gpu/drm/drm_ioctl.c | 14 +++++++++++++-
>   1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index e2df4becce62..9039a39c4324 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -373,13 +373,25 @@ drm_setclientcap(struct drm_device *dev, void *data, struct drm_file *file_priv)
>   			return -EINVAL;
>   		file_priv->supports_virtualized_cursor_plane = req->value;
>   		break;
> -	case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE:
> +	case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE: {
> +		struct drm_plane *plane;
> +		bool has_plane_with_color_pipeline = false;
> +
>   		if (!file_priv->atomic)
>   			return -EINVAL;
>   		if (req->value > 1)
>   			return -EINVAL;
> +		drm_for_each_plane(plane, dev) {
> +			if (plane->color_pipeline_property) {
> +				has_plane_with_color_pipeline = true;
> +				break;
> +			}
> +		}
> +		if (!has_plane_with_color_pipeline)
> +			return -EOPNOTSUPP;
>   		file_priv->plane_color_pipeline = req->value;
>   		break;
> +	}
>   	default:
>   		return -EINVAL;
>   	}

Re: [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

[Borah, Chaitanya Kumar]

On 7/3/2026 1:02 PM, Robert Mader wrote:
> The client cap is currently advertised unconditionally, even for drivers
> that do not support plane color pipelines. If clients supporting the later,

s/later/latter

> like Wayland compositors or tools like drm_info, enable the client cap on
> such drivers they will be left without both color pipeline and the legacy
> properties COLOR_ENCODING and COLOR_RANGE, effectively breaking YUV->RGB
> conversion support.
> 
> Prevent that by only marking the cap supported if there are actually planes
> with color pipelines.
> 
> Note: while the color pipeline replacement for the legacy properties is
> still under review (1), we can assume that it will work as a drop-in
> replacement.

This change will but a driver can also choose to export colorops like 
programmable CTM_3x4 to achieve the same.

We should also perhaps document this somewhere that if a driver supports 
LEGACY properties, it is imperative to implement some version of it with 
the color pipeline line property.

That means any plane on any hardware currently supporting
> the legacy properties will be able to offer a functionally equal color
> pipeline and there will be no technical reason keep using the legacy
> properties if both the driver and the client support the new API.
> 
> 1: https://lore.kernel.org/dri-devel/20260623164812.81110-1-harry.wentland@amd.com/
> 
> Signed-off-by: Robert Mader <robert.mader@collabora.com>
> 
> ---
> 
> Changes in v3:
>   - Move the new check behind the existing EINVAL ones
>   - Rebase on latest drm-misc-next
> 
> Changes in v2:
>   - Replace the driver feature with a simple check (suggested by Maarten
>     Lankhorst <maarten.lankhorst@linux.intel.com>)

Probably could use a Suggested-by: tag

Having said that, LGTM

Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>

>   - Expand the commit message slightly and change the title
> ---
>   drivers/gpu/drm/drm_ioctl.c | 14 +++++++++++++-
>   1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index e2df4becce62..9039a39c4324 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -373,13 +373,25 @@ drm_setclientcap(struct drm_device *dev, void *data, struct drm_file *file_priv)
>   			return -EINVAL;
>   		file_priv->supports_virtualized_cursor_plane = req->value;
>   		break;
> -	case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE:
> +	case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE: {
> +		struct drm_plane *plane;
> +		bool has_plane_with_color_pipeline = false;
> +
>   		if (!file_priv->atomic)
>   			return -EINVAL;
>   		if (req->value > 1)
>   			return -EINVAL;
> +		drm_for_each_plane(plane, dev) {
> +			if (plane->color_pipeline_property) {
> +				has_plane_with_color_pipeline = true;
> +				break;
> +			}
> +		}
> +		if (!has_plane_with_color_pipeline)
> +			return -EOPNOTSUPP;
>   		file_priv->plane_color_pipeline = req->value;
>   		break;
> +	}
>   	default:
>   		return -EINVAL;
>   	}

Re: [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

[Maarten Lankhorst]

Hey,

This probably would be useful to backport to stable, can I add those tags and merge it?

Fixes: 179ab8e7d7b3 ("drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE")
Cc: <stable@vger.kernel.org> # v6.19+

Kind regards,
~Maarten Lankhorst

On 7/3/26 09:32, Robert Mader wrote:
> The client cap is currently advertised unconditionally, even for drivers
> that do not support plane color pipelines. If clients supporting the later,
> like Wayland compositors or tools like drm_info, enable the client cap on
> such drivers they will be left without both color pipeline and the legacy
> properties COLOR_ENCODING and COLOR_RANGE, effectively breaking YUV->RGB
> conversion support.
> 
> Prevent that by only marking the cap supported if there are actually planes
> with color pipelines.
> 
> Note: while the color pipeline replacement for the legacy properties is
> still under review (1), we can assume that it will work as a drop-in
> replacement. That means any plane on any hardware currently supporting
> the legacy properties will be able to offer a functionally equal color
> pipeline and there will be no technical reason keep using the legacy
> properties if both the driver and the client support the new API.
> 
> 1: https://lore.kernel.org/dri-devel/20260623164812.81110-1-harry.wentland@amd.com/
> 
> Signed-off-by: Robert Mader <robert.mader@collabora.com>
> 
> ---
> 
> Changes in v3:
>  - Move the new check behind the existing EINVAL ones
>  - Rebase on latest drm-misc-next
> 
> Changes in v2:
>  - Replace the driver feature with a simple check (suggested by Maarten
>    Lankhorst <maarten.lankhorst@linux.intel.com>)
>  - Expand the commit message slightly and change the title
> ---
>  drivers/gpu/drm/drm_ioctl.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index e2df4becce62..9039a39c4324 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -373,13 +373,25 @@ drm_setclientcap(struct drm_device *dev, void *data, struct drm_file *file_priv)
>  			return -EINVAL;
>  		file_priv->supports_virtualized_cursor_plane = req->value;
>  		break;
> -	case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE:
> +	case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE: {
> +		struct drm_plane *plane;
> +		bool has_plane_with_color_pipeline = false;
> +
>  		if (!file_priv->atomic)
>  			return -EINVAL;
>  		if (req->value > 1)
>  			return -EINVAL;
> +		drm_for_each_plane(plane, dev) {
> +			if (plane->color_pipeline_property) {
> +				has_plane_with_color_pipeline = true;
> +				break;
> +			}
> +		}
> +		if (!has_plane_with_color_pipeline)
> +			return -EOPNOTSUPP;
>  		file_priv->plane_color_pipeline = req->value;
>  		break;
> +	}
>  	default:
>  		return -EINVAL;
>  	}

Re: [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

[Robert Mader]

Hey,

On 07.07.26 10:26, Maarten Lankhorst wrote:
> Hey,
>
> This probably would be useful to backport to stable, can I add those tags and merge it?

yes, also please feel free to apply any suggestions by Chaitanyaand.

Thanks!

>
> Fixes: 179ab8e7d7b3 ("drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE")
> Cc: <stable@vger.kernel.org> # v6.19+
>
> Kind regards,
> ~Maarten Lankhorst
>
> On 7/3/26 09:32, Robert Mader wrote:
>> The client cap is currently advertised unconditionally, even for drivers
>> that do not support plane color pipelines. If clients supporting the later,
>> like Wayland compositors or tools like drm_info, enable the client cap on
>> such drivers they will be left without both color pipeline and the legacy
>> properties COLOR_ENCODING and COLOR_RANGE, effectively breaking YUV->RGB
>> conversion support.
>>
>> Prevent that by only marking the cap supported if there are actually planes
>> with color pipelines.
>>
>> Note: while the color pipeline replacement for the legacy properties is
>> still under review (1), we can assume that it will work as a drop-in
>> replacement. That means any plane on any hardware currently supporting
>> the legacy properties will be able to offer a functionally equal color
>> pipeline and there will be no technical reason keep using the legacy
>> properties if both the driver and the client support the new API.
>>
>> 1: https://lore.kernel.org/dri-devel/20260623164812.81110-1-harry.wentland@amd.com/
>>
>> Signed-off-by: Robert Mader <robert.mader@collabora.com>
>>
>> ---
>>
>> Changes in v3:
>>   - Move the new check behind the existing EINVAL ones
>>   - Rebase on latest drm-misc-next
>>
>> Changes in v2:
>>   - Replace the driver feature with a simple check (suggested by Maarten
>>     Lankhorst <maarten.lankhorst@linux.intel.com>)
>>   - Expand the commit message slightly and change the title
>> ---
>>   drivers/gpu/drm/drm_ioctl.c | 14 +++++++++++++-
>>   1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>> index e2df4becce62..9039a39c4324 100644
>> --- a/drivers/gpu/drm/drm_ioctl.c
>> +++ b/drivers/gpu/drm/drm_ioctl.c
>> @@ -373,13 +373,25 @@ drm_setclientcap(struct drm_device *dev, void *data, struct drm_file *file_priv)
>>   			return -EINVAL;
>>   		file_priv->supports_virtualized_cursor_plane = req->value;
>>   		break;
>> -	case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE:
>> +	case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE: {
>> +		struct drm_plane *plane;
>> +		bool has_plane_with_color_pipeline = false;
>> +
>>   		if (!file_priv->atomic)
>>   			return -EINVAL;
>>   		if (req->value > 1)
>>   			return -EINVAL;
>> +		drm_for_each_plane(plane, dev) {
>> +			if (plane->color_pipeline_property) {
>> +				has_plane_with_color_pipeline = true;
>> +				break;
>> +			}
>> +		}
>> +		if (!has_plane_with_color_pipeline)
>> +			return -EOPNOTSUPP;
>>   		file_priv->plane_color_pipeline = req->value;
>>   		break;
>> +	}
>>   	default:
>>   		return -EINVAL;
>>   	}

-- 
Robert Mader
Consultant Software Developer

Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718

Re: [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

[Maarten Lankhorst]

Hey,

On 7/7/26 10:03, Borah, Chaitanya Kumar wrote:
> 
> 
> On 7/3/2026 1:02 PM, Robert Mader wrote:
>> The client cap is currently advertised unconditionally, even for drivers
>> that do not support plane color pipelines. If clients supporting the later,
> 
> s/later/latter
> 
>> like Wayland compositors or tools like drm_info, enable the client cap on
>> such drivers they will be left without both color pipeline and the legacy
>> properties COLOR_ENCODING and COLOR_RANGE, effectively breaking YUV->RGB
>> conversion support.
>>
>> Prevent that by only marking the cap supported if there are actually planes
>> with color pipelines.
>>
>> Note: while the color pipeline replacement for the legacy properties is
>> still under review (1), we can assume that it will work as a drop-in
>> replacement.
> 
> This change will but a driver can also choose to export colorops like programmable CTM_3x4 to achieve the same.
> 
> We should also perhaps document this somewhere that if a driver supports LEGACY properties, it is imperative to implement some version of it with the color pipeline line property.

Would this be doable inside drm core? Implement the color pipeline properties, get the fixed pipeline for free?

But thanks for all feedback, as I was about to push this patch, I noticed it still uses -EOPNOTSUPP, can it be changed to -EINVAL?

~Maarten

Re: [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

[Robert Mader]

Hi,

On 07.07.26 15:01, Maarten Lankhorst wrote:
> Hey,
>
> On 7/7/26 10:03, Borah, Chaitanya Kumar wrote:
>>
>> On 7/3/2026 1:02 PM, Robert Mader wrote:
>>> The client cap is currently advertised unconditionally, even for drivers
>>> that do not support plane color pipelines. If clients supporting the later,
>> s/later/latter
>>
>>> like Wayland compositors or tools like drm_info, enable the client cap on
>>> such drivers they will be left without both color pipeline and the legacy
>>> properties COLOR_ENCODING and COLOR_RANGE, effectively breaking YUV->RGB
>>> conversion support.
>>>
>>> Prevent that by only marking the cap supported if there are actually planes
>>> with color pipelines.
>>>
>>> Note: while the color pipeline replacement for the legacy properties is
>>> still under review (1), we can assume that it will work as a drop-in
>>> replacement.
>> This change will but a driver can also choose to export colorops like programmable CTM_3x4 to achieve the same.
>>
>> We should also perhaps document this somewhere that if a driver supports LEGACY properties, it is imperative to implement some version of it with the color pipeline line property.
> Would this be doable inside drm core? Implement the color pipeline properties, get the fixed pipeline for free?
>
> But thanks for all feedback, as I was about to push this patch, I noticed it still uses -EOPNOTSUPP, can it be changed to -EINVAL?

For existing users it shouldn't make a difference. drm_info and Weston 
just check for "drmSetClientCap() == 0" - and old kernels without the 
cap will also return -EINVAL AFAICS.

I personally find -EOPNOTSUPP more appropriate and more in line with 
other return values in that function - but no strong opinion, thus feel 
free to change while applying (or I can resend the patch accordingly if 
you prefer).

Robert

>
> ~Maarten

-- 
Robert Mader
Consultant Software Developer

Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718

Re: [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

[Maarten Lankhorst]

Hello Robert,

On 7/7/26 15:15, Robert Mader wrote:
> Hi,
> 
> On 07.07.26 15:01, Maarten Lankhorst wrote:
>> Hey,
>>
>> On 7/7/26 10:03, Borah, Chaitanya Kumar wrote:
>>>
>>> On 7/3/2026 1:02 PM, Robert Mader wrote:
>>>> The client cap is currently advertised unconditionally, even for drivers
>>>> that do not support plane color pipelines. If clients supporting the later,
>>> s/later/latter
>>>
>>>> like Wayland compositors or tools like drm_info, enable the client cap on
>>>> such drivers they will be left without both color pipeline and the legacy
>>>> properties COLOR_ENCODING and COLOR_RANGE, effectively breaking YUV->RGB
>>>> conversion support.
>>>>
>>>> Prevent that by only marking the cap supported if there are actually planes
>>>> with color pipelines.
>>>>
>>>> Note: while the color pipeline replacement for the legacy properties is
>>>> still under review (1), we can assume that it will work as a drop-in
>>>> replacement.
>>> This change will but a driver can also choose to export colorops like programmable CTM_3x4 to achieve the same.
>>>
>>> We should also perhaps document this somewhere that if a driver supports LEGACY properties, it is imperative to implement some version of it with the color pipeline line property.
>> Would this be doable inside drm core? Implement the color pipeline properties, get the fixed pipeline for free?
>>
>> But thanks for all feedback, as I was about to push this patch, I noticed it still uses -EOPNOTSUPP, can it be changed to -EINVAL?
> 
> For existing users it shouldn't make a difference. drm_info and Weston just check for "drmSetClientCap() == 0" - and old kernels without the cap will also return -EINVAL AFAICS.
> 
> I personally find -EOPNOTSUPP more appropriate and more in line with other return values in that function - but no strong opinion, thus feel free to change while applying (or I can resend the patch accordingly if you prefer).

Yeah no worries, I looked at the code and it seems -EOPNOTSUPP is used a lot in getcap/setcap. In particular when driver support is missing
for features, I'll leave it as is and push it now.

Kind regards,
~Maarten

Re: [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

[Borah, Chaitanya Kumar]

On 7/7/2026 6:31 PM, Maarten Lankhorst wrote:
> Hey,
> 
> On 7/7/26 10:03, Borah, Chaitanya Kumar wrote:
>>
>> On 7/3/2026 1:02 PM, Robert Mader wrote:
>>> The client cap is currently advertised unconditionally, even for drivers
>>> that do not support plane color pipelines. If clients supporting the later,
>> s/later/latter
>>
>>> like Wayland compositors or tools like drm_info, enable the client cap on
>>> such drivers they will be left without both color pipeline and the legacy
>>> properties COLOR_ENCODING and COLOR_RANGE, effectively breaking YUV->RGB
>>> conversion support.
>>>
>>> Prevent that by only marking the cap supported if there are actually planes
>>> with color pipelines.
>>>
>>> Note: while the color pipeline replacement for the legacy properties is
>>> still under review (1), we can assume that it will work as a drop-in
>>> replacement.
>> This change will but a driver can also choose to export colorops like programmable CTM_3x4 to achieve the same.
>>
>> We should also perhaps document this somewhere that if a driver supports LEGACY properties, it is imperative to implement some version of it with the color pipeline line property.
> Would this be doable inside drm core? Implement the color pipeline properties, get the fixed pipeline for free?

Right now, the Bypass(default) pipeline is automatically created when we 
call drm_plane_create_color_pipeline_property(), we could come up with a 
similar helper that could also create a pipeline that replaces the 
legacy properties.

But this can't replace the existing helper entirely because some HW 
(though unlikely) might not support YUV buffers.

==
Chaitanya