[PATCH v3 0/4] User readable error codes on atomic_ioctl failure

[PATCH v3 0/4] User readable error codes on atomic_ioctl failure

[Arun R Murthy]

The series focuses on providing a user readable error value on a failure
in drm_atomic_ioctl(). Usually -EINVAL is returned in most of the error
cases and it is difficult for the user to decode the error and get to
know the real cause for the error. If user gets to know the reason for
the error then corrective measurements can be taken up.

TODO: driver specific error codes are to be added and will be done in
the follow-up patches.

The IGT related changes are pushed for review @
https://patchwork.freedesktop.org/series/153330/

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
Arun R Murthy (4):
      drm: Define user readable error codes for atomic ioctl
      drm/atomic: Add error_code element in atomic_state
      drm/atomic: Return user readable error in atomic_ioctl
      drm/i915/display: Error codes for async flip failures

 drivers/gpu/drm/drm_atomic.c                 |  6 +++
 drivers/gpu/drm/drm_atomic_uapi.c            | 60 +++++++++++++++++++++++-----
 drivers/gpu/drm/i915/display/intel_display.c |  4 ++
 include/drm/drm_atomic.h                     |  7 ++++
 include/uapi/drm/drm_mode.h                  | 42 +++++++++++++++++++
 5 files changed, 109 insertions(+), 10 deletions(-)
---
base-commit: cca87ca63e2f5b8a785dc59c23e526987530b27f
change-id: 20250728-atomic-c9713fd357e4

Best regards,
-- 
Arun R Murthy <arun.r.murthy@intel.com>

[PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

[Arun R Murthy]

There can be multiple reasons for a failure in atomic_ioctl. Most often
in these error conditions -EINVAL is returned. User/Compositor would
have to blindly take a call on failure of this ioctl so as to use
ALLOW_MODESET or any. It would be good if user/compositor gets a
readable error code on failure so they can take proper corrections in
the next commit.
The struct drm_mode_atomic is being passed by the user/compositor which
holds the properties for modeset/flip. Reusing the same struct for
returning the error code in case of failure can save by creating a new
uapi/interface for returning the error code.
The element 'reserved' in the struct drm_mode_atomic is used for
returning the user readable error code. This points to the struct
drm_mode_atomic_err_code. Failure reasons have been initialized in
DRM_MODE_ATOMIC_FAILURE_REASON.

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
 include/uapi/drm/drm_mode.h | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index a122bea2559387576150236e3a88f99c24ad3138..f0986a3fe9a7d61e57e9a9a5ec01a604343f6930 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -45,6 +45,7 @@ extern "C" {
 #define DRM_CONNECTOR_NAME_LEN	32
 #define DRM_DISPLAY_MODE_LEN	32
 #define DRM_PROP_NAME_LEN	32
+#define DRM_MODE_ATOMIC_FAILURE_STRING_LEN	64
 
 #define DRM_MODE_TYPE_BUILTIN	(1<<0) /* deprecated */
 #define DRM_MODE_TYPE_CLOCK_C	((1<<1) | DRM_MODE_TYPE_BUILTIN) /* deprecated */
@@ -1157,6 +1158,47 @@ struct drm_mode_destroy_dumb {
 		DRM_MODE_ATOMIC_NONBLOCK |\
 		DRM_MODE_ATOMIC_ALLOW_MODESET)
 
+#define DRM_MODE_ATOMIC_FAILURE_REASON \
+	FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC capability not enabled") \
+	FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
+	FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy DRM_MODE_PAGE_FLIP_ASYNC not to be used in atomic ioctl") \
+	FAILURE_REASON(DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY, "requesting page-flip event with TEST_ONLY") \
+	FAILURE_REASON(DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET, "Need full modeset on this crtc") \
+	FAILURE_REASON(DRM_MODE_ATOMIC_NEED_FULL_MODESET, "Need full modeset on all the connected crtc's") \
+	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE, "Async flip not supported on this plane") \
+	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED, "Modifier not supported on this plane with async flip") \
+	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED, "No property change allowed when async flip is enabled")
+
+#define FAILURE_REASON(flag, reason) flag,
+typedef enum {
+	DRM_MODE_ATOMIC_FAILURE_REASON
+} drm_mode_atomic_failure_flag;
+#undef FAILURE_REASON
+
+#define FAILURE_REASON(flag, reason) #reason,
+extern const char *drm_mode_atomic_failure_string[];
+#undef FAILURE_REASON
+
+/**
+ * drm_mode_atomic_err_code - struct to store the error code
+ *
+ * pointer to this struct will be stored in reserved variable of
+ * struct drm_mode_atomic to report the failure cause to the user.
+ *
+ * @failure_flags: error codes defined in drm_atomic_failure.failure_flag
+ * @failure_string_ptr: pointer to user readable error message drm_mode_failure.failure_string
+ * @failure_obj_ptr: pointer to the drm_object that caused error
+ * @reserved: reserved for future use
+ * @count_objs: count of drm_objects if multiple drm_objects caused error
+ */
+struct drm_mode_atomic_err_code {
+	__u64 failure_flags;
+	__u64 failure_objs_ptr;
+	__u64 reserved;
+	__u32 count_objs;
+	char failure_string[DRM_MODE_ATOMIC_FAILURE_STRING_LEN];
+};
+
 struct drm_mode_atomic {
 	__u32 flags;
 	__u32 count_objs;

-- 
2.25.1

Re: [PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

[Jani Nikula]

On Fri, 22 Aug 2025, Arun R Murthy <arun.r.murthy@intel.com> wrote:
> There can be multiple reasons for a failure in atomic_ioctl. Most often
> in these error conditions -EINVAL is returned. User/Compositor would
> have to blindly take a call on failure of this ioctl so as to use
> ALLOW_MODESET or any. It would be good if user/compositor gets a
> readable error code on failure so they can take proper corrections in
> the next commit.
> The struct drm_mode_atomic is being passed by the user/compositor which
> holds the properties for modeset/flip. Reusing the same struct for
> returning the error code in case of failure can save by creating a new
> uapi/interface for returning the error code.
> The element 'reserved' in the struct drm_mode_atomic is used for
> returning the user readable error code. This points to the struct
> drm_mode_atomic_err_code. Failure reasons have been initialized in
> DRM_MODE_ATOMIC_FAILURE_REASON.

At the moment, I'm not (yet) convinced any of this will work, even as a
concept.

Even so, I'll comment on some of the choices in the series.

> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
>  include/uapi/drm/drm_mode.h | 42 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index a122bea2559387576150236e3a88f99c24ad3138..f0986a3fe9a7d61e57e9a9a5ec01a604343f6930 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -45,6 +45,7 @@ extern "C" {
>  #define DRM_CONNECTOR_NAME_LEN	32
>  #define DRM_DISPLAY_MODE_LEN	32
>  #define DRM_PROP_NAME_LEN	32
> +#define DRM_MODE_ATOMIC_FAILURE_STRING_LEN	64
>  
>  #define DRM_MODE_TYPE_BUILTIN	(1<<0) /* deprecated */
>  #define DRM_MODE_TYPE_CLOCK_C	((1<<1) | DRM_MODE_TYPE_BUILTIN) /* deprecated */
> @@ -1157,6 +1158,47 @@ struct drm_mode_destroy_dumb {
>  		DRM_MODE_ATOMIC_NONBLOCK |\
>  		DRM_MODE_ATOMIC_ALLOW_MODESET)
>  
> +#define DRM_MODE_ATOMIC_FAILURE_REASON \
> +	FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC capability not enabled") \

Please don't add macros that expect other macros in the context. They
become very confusing. Just pass in the other macro to use. See MACRO__
in include/drm/intel/pciids.h for an example.

> +	FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
> +	FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy DRM_MODE_PAGE_FLIP_ASYNC not to be used in atomic ioctl") \
> +	FAILURE_REASON(DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY, "requesting page-flip event with TEST_ONLY") \
> +	FAILURE_REASON(DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET, "Need full modeset on this crtc") \
> +	FAILURE_REASON(DRM_MODE_ATOMIC_NEED_FULL_MODESET, "Need full modeset on all the connected crtc's") \
> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE, "Async flip not supported on this plane") \
> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED, "Modifier not supported on this plane with async flip") \
> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED, "No property change allowed when async flip is enabled")
> +
> +#define FAILURE_REASON(flag, reason) flag,
> +typedef enum {
> +	DRM_MODE_ATOMIC_FAILURE_REASON
> +} drm_mode_atomic_failure_flag;
> +#undef FAILURE_REASON

This is a uapi header. Do we really want all of that macro trickery here
in the first place? What's wrong with just a plain enum? (Or macros.)

> +
> +#define FAILURE_REASON(flag, reason) #reason,
> +extern const char *drm_mode_atomic_failure_string[];
> +#undef FAILURE_REASON

Data is not an interface. Don't expose arrays like this. Who is even
going to know what its size is? Again, uapi header, where does it point,
what address space is it?

> +
> +/**
> + * drm_mode_atomic_err_code - struct to store the error code
> + *
> + * pointer to this struct will be stored in reserved variable of
> + * struct drm_mode_atomic to report the failure cause to the user.
> + *
> + * @failure_flags: error codes defined in drm_atomic_failure.failure_flag

Flags? As in a mask of multiple things? Is 64 going to be enough for
everyone, all conditions in all drivers?

OTOH, what's the promise wrt multiple reasons? Practically all drivers
bail out at the sight of first issue, and it's usually pretty much
meaningless to continue to figure out *other* reasons after that.

And this brings us to one of my main concerns on making this fly:

You bail out on the first thing, but you can't expect all drivers to
check stuff in the same order. It's not practical. So different drivers
will likely return different reasons for virtually the same
condition. So how is userspace going to handle that?

> + * @failure_string_ptr: pointer to user readable error message drm_mode_failure.failure_string

Is the string part of uapi, and can never change? Doesn't sound
great. What's wrong with just a plain enum?

> + * @failure_obj_ptr: pointer to the drm_object that caused error
> + * @reserved: reserved for future use
> + * @count_objs: count of drm_objects if multiple drm_objects caused error
> + */
> +struct drm_mode_atomic_err_code {
> +	__u64 failure_flags;
> +	__u64 failure_objs_ptr;
> +	__u64 reserved;
> +	__u32 count_objs;
> +	char failure_string[DRM_MODE_ATOMIC_FAILURE_STRING_LEN];
> +};
> +
>  struct drm_mode_atomic {
>  	__u32 flags;
>  	__u32 count_objs;

-- 
Jani Nikula, Intel

Re: [PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

[Murthy, Arun R]

On 22-08-2025 16:07, Jani Nikula wrote:
> On Fri, 22 Aug 2025, Arun R Murthy <arun.r.murthy@intel.com> wrote:
>> There can be multiple reasons for a failure in atomic_ioctl. Most often
>> in these error conditions -EINVAL is returned. User/Compositor would
>> have to blindly take a call on failure of this ioctl so as to use
>> ALLOW_MODESET or any. It would be good if user/compositor gets a
>> readable error code on failure so they can take proper corrections in
>> the next commit.
>> The struct drm_mode_atomic is being passed by the user/compositor which
>> holds the properties for modeset/flip. Reusing the same struct for
>> returning the error code in case of failure can save by creating a new
>> uapi/interface for returning the error code.
>> The element 'reserved' in the struct drm_mode_atomic is used for
>> returning the user readable error code. This points to the struct
>> drm_mode_atomic_err_code. Failure reasons have been initialized in
>> DRM_MODE_ATOMIC_FAILURE_REASON.
> At the moment, I'm not (yet) convinced any of this will work, even as a
> concept.
km_flip test in IGT has been run and is working fine with these patch 
series. Also
the existing kms_atomic test with atomic_invalid_test has been modified to
test this error code(https://patchwork.freedesktop.org/series/153330/)

Am I missing anything over here?

> Even so, I'll comment on some of the choices in the series.
>
>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>> ---
>>   include/uapi/drm/drm_mode.h | 42 ++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 42 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index a122bea2559387576150236e3a88f99c24ad3138..f0986a3fe9a7d61e57e9a9a5ec01a604343f6930 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -45,6 +45,7 @@ extern "C" {
>>   #define DRM_CONNECTOR_NAME_LEN	32
>>   #define DRM_DISPLAY_MODE_LEN	32
>>   #define DRM_PROP_NAME_LEN	32
>> +#define DRM_MODE_ATOMIC_FAILURE_STRING_LEN	64
>>   
>>   #define DRM_MODE_TYPE_BUILTIN	(1<<0) /* deprecated */
>>   #define DRM_MODE_TYPE_CLOCK_C	((1<<1) | DRM_MODE_TYPE_BUILTIN) /* deprecated */
>> @@ -1157,6 +1158,47 @@ struct drm_mode_destroy_dumb {
>>   		DRM_MODE_ATOMIC_NONBLOCK |\
>>   		DRM_MODE_ATOMIC_ALLOW_MODESET)
>>   
>> +#define DRM_MODE_ATOMIC_FAILURE_REASON \
>> +	FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC capability not enabled") \
> Please don't add macros that expect other macros in the context. They
> become very confusing. Just pass in the other macro to use. See MACRO__
> in include/drm/intel/pciids.h for an example.
Here we are mapping an error_code defined as enum with a corresponding 
string
using the X macros.

Anyway will have a look at the macro in include/drm/intel/pciids.h


>> +	FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
>> +	FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy DRM_MODE_PAGE_FLIP_ASYNC not to be used in atomic ioctl") \
>> +	FAILURE_REASON(DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY, "requesting page-flip event with TEST_ONLY") \
>> +	FAILURE_REASON(DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET, "Need full modeset on this crtc") \
>> +	FAILURE_REASON(DRM_MODE_ATOMIC_NEED_FULL_MODESET, "Need full modeset on all the connected crtc's") \
>> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE, "Async flip not supported on this plane") \
>> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED, "Modifier not supported on this plane with async flip") \
>> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED, "No property change allowed when async flip is enabled")
>> +
>> +#define FAILURE_REASON(flag, reason) flag,
>> +typedef enum {
>> +	DRM_MODE_ATOMIC_FAILURE_REASON
>> +} drm_mode_atomic_failure_flag;
>> +#undef FAILURE_REASON
> This is a uapi header. Do we really want all of that macro trickery here
> in the first place? What's wrong with just a plain enum? (Or macros.)
This is defined as enum. We have two separate list one for enum and other
for error message(string) but  upon user adding a new element/error_code 
in the
enum, there can be a possibility of missing adding the error string. So 
have linked
enum with the corresponding error message/string so both are at a single 
place
and upon adding new entry will be easy for the user.
>> +
>> +#define FAILURE_REASON(flag, reason) #reason,
>> +extern const char *drm_mode_atomic_failure_string[];
>> +#undef FAILURE_REASON
> Data is not an interface. Don't expose arrays like this. Who is even
> going to know what its size is? Again, uapi header, where does it point,
> what address space is it?
>
Sorry missed adding documentation for this. Will add in my next series.
>> +
>> +/**
>> + * drm_mode_atomic_err_code - struct to store the error code
>> + *
>> + * pointer to this struct will be stored in reserved variable of
>> + * struct drm_mode_atomic to report the failure cause to the user.
>> + *
>> + * @failure_flags: error codes defined in drm_atomic_failure.failure_flag
> Flags? As in a mask of multiple things? Is 64 going to be enough for
> everyone, all conditions in all drivers?
Should be more that sufficient, this is an enum.
> OTOH, what's the promise wrt multiple reasons? Practically all drivers
> bail out at the sight of first issue, and it's usually pretty much
> meaningless to continue to figure out *other* reasons after that.
>
> And this brings us to one of my main concerns on making this fly:
>
> You bail out on the first thing, but you can't expect all drivers to
> check stuff in the same order. It's not practical. So different drivers
> will likely return different reasons for virtually the same
> condition. So how is userspace going to handle that?
Most of the error check is in the drm-core and these are common across 
the drivers.
Upon drivers sending driver specific error code, the compositor may not 
be able to
handle the error code. But in cases required compositor changes can be 
added so
as to handle them. In general the generic error conditions that are met 
by compositor
and for which compositor can take corrective measurements are listed 
down first.
>> + * @failure_string_ptr: pointer to user readable error message drm_mode_failure.failure_string
> Is the string part of uapi, and can never change? Doesn't sound
> great. What's wrong with just a plain enum?
enum is sufficient enough and this string is added so that this error 
message

can be printed out in the compositor logs for the user.

Thanks and Regards,
Arun R Murthy
-------------------

>> + * @failure_obj_ptr: pointer to the drm_object that caused error
>> + * @reserved: reserved for future use
>> + * @count_objs: count of drm_objects if multiple drm_objects caused error
>> + */
>> +struct drm_mode_atomic_err_code {
>> +	__u64 failure_flags;
>> +	__u64 failure_objs_ptr;
>> +	__u64 reserved;
>> +	__u32 count_objs;
>> +	char failure_string[DRM_MODE_ATOMIC_FAILURE_STRING_LEN];
>> +};
>> +
>>   struct drm_mode_atomic {
>>   	__u32 flags;
>>   	__u32 count_objs;

Re: [PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

[Jani Nikula]

On Sat, 23 Aug 2025, "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> On 22-08-2025 16:07, Jani Nikula wrote:
>> On Fri, 22 Aug 2025, Arun R Murthy <arun.r.murthy@intel.com> wrote:
>>> There can be multiple reasons for a failure in atomic_ioctl. Most often
>>> in these error conditions -EINVAL is returned. User/Compositor would
>>> have to blindly take a call on failure of this ioctl so as to use
>>> ALLOW_MODESET or any. It would be good if user/compositor gets a
>>> readable error code on failure so they can take proper corrections in
>>> the next commit.
>>> The struct drm_mode_atomic is being passed by the user/compositor which
>>> holds the properties for modeset/flip. Reusing the same struct for
>>> returning the error code in case of failure can save by creating a new
>>> uapi/interface for returning the error code.
>>> The element 'reserved' in the struct drm_mode_atomic is used for
>>> returning the user readable error code. This points to the struct
>>> drm_mode_atomic_err_code. Failure reasons have been initialized in
>>> DRM_MODE_ATOMIC_FAILURE_REASON.
>> At the moment, I'm not (yet) convinced any of this will work, even as a
>> concept.
> km_flip test in IGT has been run and is working fine with these patch 
> series. Also
> the existing kms_atomic test with atomic_invalid_test has been modified to
> test this error code(https://patchwork.freedesktop.org/series/153330/)
>
> Am I missing anything over here?

Having a few tests in IGT does not mean a non-trivial userspace
(compositor) can use the information in a useful way.

>> Even so, I'll comment on some of the choices in the series.
>>
>>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>>> ---
>>>   include/uapi/drm/drm_mode.h | 42 ++++++++++++++++++++++++++++++++++++++++++
>>>   1 file changed, 42 insertions(+)
>>>
>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>> index a122bea2559387576150236e3a88f99c24ad3138..f0986a3fe9a7d61e57e9a9a5ec01a604343f6930 100644
>>> --- a/include/uapi/drm/drm_mode.h
>>> +++ b/include/uapi/drm/drm_mode.h
>>> @@ -45,6 +45,7 @@ extern "C" {
>>>   #define DRM_CONNECTOR_NAME_LEN	32
>>>   #define DRM_DISPLAY_MODE_LEN	32
>>>   #define DRM_PROP_NAME_LEN	32
>>> +#define DRM_MODE_ATOMIC_FAILURE_STRING_LEN	64
>>>   
>>>   #define DRM_MODE_TYPE_BUILTIN	(1<<0) /* deprecated */
>>>   #define DRM_MODE_TYPE_CLOCK_C	((1<<1) | DRM_MODE_TYPE_BUILTIN) /* deprecated */
>>> @@ -1157,6 +1158,47 @@ struct drm_mode_destroy_dumb {
>>>   		DRM_MODE_ATOMIC_NONBLOCK |\
>>>   		DRM_MODE_ATOMIC_ALLOW_MODESET)
>>>   
>>> +#define DRM_MODE_ATOMIC_FAILURE_REASON \
>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC capability not enabled") \
>> Please don't add macros that expect other macros in the context. They
>> become very confusing. Just pass in the other macro to use. See MACRO__
>> in include/drm/intel/pciids.h for an example.
> Here we are mapping an error_code defined as enum with a corresponding 
> string
> using the X macros.
>
> Anyway will have a look at the macro in include/drm/intel/pciids.h
>
>
>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy DRM_MODE_PAGE_FLIP_ASYNC not to be used in atomic ioctl") \
>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY, "requesting page-flip event with TEST_ONLY") \
>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET, "Need full modeset on this crtc") \
>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_NEED_FULL_MODESET, "Need full modeset on all the connected crtc's") \
>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE, "Async flip not supported on this plane") \
>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED, "Modifier not supported on this plane with async flip") \
>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED, "No property change allowed when async flip is enabled")
>>> +
>>> +#define FAILURE_REASON(flag, reason) flag,
>>> +typedef enum {
>>> +	DRM_MODE_ATOMIC_FAILURE_REASON
>>> +} drm_mode_atomic_failure_flag;
>>> +#undef FAILURE_REASON
>> This is a uapi header. Do we really want all of that macro trickery here
>> in the first place? What's wrong with just a plain enum? (Or macros.)
> This is defined as enum. We have two separate list one for enum and
> other for error message(string) but  upon user adding a new
> element/error_code in the enum, there can be a possibility of missing
> adding the error string. So have linked enum with the corresponding
> error message/string so both are at a single place and upon adding new
> entry will be easy for the user.

I think the overall point is this:

a) If the messages are fixed for each enum, there is no point in passing
   that message across the ioctl. Userspace can map the enums and
   messages directly.

b) If the messages are not fixed, I see no point in having the above
   fixed messages at all.

c) If the messages are not fixed, but you want to have default messages,
   the messages do not belong in the uapi header at all. Hide them in
   the kernel.

>>> +
>>> +#define FAILURE_REASON(flag, reason) #reason,
>>> +extern const char *drm_mode_atomic_failure_string[];
>>> +#undef FAILURE_REASON
>> Data is not an interface. Don't expose arrays like this. Who is even
>> going to know what its size is? Again, uapi header, where does it point,
>> what address space is it?
>>
> Sorry missed adding documentation for this. Will add in my next series.

Documentation does not fix the issue that data is not an interface.

>>> +
>>> +/**
>>> + * drm_mode_atomic_err_code - struct to store the error code
>>> + *
>>> + * pointer to this struct will be stored in reserved variable of
>>> + * struct drm_mode_atomic to report the failure cause to the user.
>>> + *
>>> + * @failure_flags: error codes defined in drm_atomic_failure.failure_flag
>> Flags? As in a mask of multiple things? Is 64 going to be enough for
>> everyone, all conditions in all drivers?
> Should be more that sufficient, this is an enum.

Then don't call it "flags".

>> OTOH, what's the promise wrt multiple reasons? Practically all drivers
>> bail out at the sight of first issue, and it's usually pretty much
>> meaningless to continue to figure out *other* reasons after that.
>>
>> And this brings us to one of my main concerns on making this fly:
>>
>> You bail out on the first thing, but you can't expect all drivers to
>> check stuff in the same order. It's not practical. So different drivers
>> will likely return different reasons for virtually the same
>> condition. So how is userspace going to handle that?
> Most of the error check is in the drm-core and these are common across
> the drivers.  Upon drivers sending driver specific error code, the
> compositor may not be able to handle the error code. But in cases
> required compositor changes can be added so as to handle them. In
> general the generic error conditions that are met by compositor and
> for which compositor can take corrective measurements are listed down
> first.

I think we're going to need a handful of error codes for starters, along
with compositor changes that make meaningful and benefitial usage of the
error codes.

>>> + * @failure_string_ptr: pointer to user readable error message drm_mode_failure.failure_string
>> Is the string part of uapi, and can never change? Doesn't sound
>> great. What's wrong with just a plain enum?
> enum is sufficient enough and this string is added so that this error 
> message
>
> can be printed out in the compositor logs for the user.
>
> Thanks and Regards,
> Arun R Murthy
> -------------------
>
>>> + * @failure_obj_ptr: pointer to the drm_object that caused error
>>> + * @reserved: reserved for future use
>>> + * @count_objs: count of drm_objects if multiple drm_objects caused error
>>> + */
>>> +struct drm_mode_atomic_err_code {
>>> +	__u64 failure_flags;
>>> +	__u64 failure_objs_ptr;
>>> +	__u64 reserved;
>>> +	__u32 count_objs;
>>> +	char failure_string[DRM_MODE_ATOMIC_FAILURE_STRING_LEN];
>>> +};
>>> +
>>>   struct drm_mode_atomic {
>>>   	__u32 flags;
>>>   	__u32 count_objs;

-- 
Jani Nikula, Intel

Re: [PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

[Murthy, Arun R]

[-- Attachment #1: Type: text/plain, Size: 7855 bytes --]

On 25-08-2025 15:14, Jani Nikula wrote:
> On Sat, 23 Aug 2025, "Murthy, Arun R"<arun.r.murthy@intel.com> wrote:
>> On 22-08-2025 16:07, Jani Nikula wrote:
>>> On Fri, 22 Aug 2025, Arun R Murthy<arun.r.murthy@intel.com> wrote:
>>>> There can be multiple reasons for a failure in atomic_ioctl. Most often
>>>> in these error conditions -EINVAL is returned. User/Compositor would
>>>> have to blindly take a call on failure of this ioctl so as to use
>>>> ALLOW_MODESET or any. It would be good if user/compositor gets a
>>>> readable error code on failure so they can take proper corrections in
>>>> the next commit.
>>>> The struct drm_mode_atomic is being passed by the user/compositor which
>>>> holds the properties for modeset/flip. Reusing the same struct for
>>>> returning the error code in case of failure can save by creating a new
>>>> uapi/interface for returning the error code.
>>>> The element 'reserved' in the struct drm_mode_atomic is used for
>>>> returning the user readable error code. This points to the struct
>>>> drm_mode_atomic_err_code. Failure reasons have been initialized in
>>>> DRM_MODE_ATOMIC_FAILURE_REASON.
>>> At the moment, I'm not (yet) convinced any of this will work, even as a
>>> concept.
>> km_flip test in IGT has been run and is working fine with these patch
>> series. Also
>> the existing kms_atomic test with atomic_invalid_test has been modified to
>> test this error code(https://patchwork.freedesktop.org/series/153330/)
>>
>> Am I missing anything over here?
> Having a few tests in IGT does not mean a non-trivial userspace
> (compositor) can use the information in a useful way.
>
>>> Even so, I'll comment on some of the choices in the series.
>>>
>>>> Signed-off-by: Arun R Murthy<arun.r.murthy@intel.com>
>>>> ---
>>>>    include/uapi/drm/drm_mode.h | 42 ++++++++++++++++++++++++++++++++++++++++++
>>>>    1 file changed, 42 insertions(+)
>>>>
>>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>>> index a122bea2559387576150236e3a88f99c24ad3138..f0986a3fe9a7d61e57e9a9a5ec01a604343f6930 100644
>>>> --- a/include/uapi/drm/drm_mode.h
>>>> +++ b/include/uapi/drm/drm_mode.h
>>>> @@ -45,6 +45,7 @@ extern "C" {
>>>>    #define DRM_CONNECTOR_NAME_LEN	32
>>>>    #define DRM_DISPLAY_MODE_LEN	32
>>>>    #define DRM_PROP_NAME_LEN	32
>>>> +#define DRM_MODE_ATOMIC_FAILURE_STRING_LEN	64
>>>>    
>>>>    #define DRM_MODE_TYPE_BUILTIN	(1<<0) /* deprecated */
>>>>    #define DRM_MODE_TYPE_CLOCK_C	((1<<1) | DRM_MODE_TYPE_BUILTIN) /* deprecated */
>>>> @@ -1157,6 +1158,47 @@ struct drm_mode_destroy_dumb {
>>>>    		DRM_MODE_ATOMIC_NONBLOCK |\
>>>>    		DRM_MODE_ATOMIC_ALLOW_MODESET)
>>>>    
>>>> +#define DRM_MODE_ATOMIC_FAILURE_REASON \
>>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC capability not enabled") \
>>> Please don't add macros that expect other macros in the context. They
>>> become very confusing. Just pass in the other macro to use. See MACRO__
>>> in include/drm/intel/pciids.h for an example.
>> Here we are mapping an error_code defined as enum with a corresponding
>> string
>> using the X macros.
>>
>> Anyway will have a look at the macro in include/drm/intel/pciids.h
>>
>>
>>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
>>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy DRM_MODE_PAGE_FLIP_ASYNC not to be used in atomic ioctl") \
>>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY, "requesting page-flip event with TEST_ONLY") \
>>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET, "Need full modeset on this crtc") \
>>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_NEED_FULL_MODESET, "Need full modeset on all the connected crtc's") \
>>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE, "Async flip not supported on this plane") \
>>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED, "Modifier not supported on this plane with async flip") \
>>>> +	FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED, "No property change allowed when async flip is enabled")
>>>> +
>>>> +#define FAILURE_REASON(flag, reason) flag,
>>>> +typedef enum {
>>>> +	DRM_MODE_ATOMIC_FAILURE_REASON
>>>> +} drm_mode_atomic_failure_flag;
>>>> +#undef FAILURE_REASON
>>> This is a uapi header. Do we really want all of that macro trickery here
>>> in the first place? What's wrong with just a plain enum? (Or macros.)
>> This is defined as enum. We have two separate list one for enum and
>> other for error message(string) but  upon user adding a new
>> element/error_code in the enum, there can be a possibility of missing
>> adding the error string. So have linked enum with the corresponding
>> error message/string so both are at a single place and upon adding new
>> entry will be easy for the user.
> I think the overall point is this:
>
> a) If the messages are fixed for each enum, there is no point in passing
>     that message across the ioctl. Userspace can map the enums and
>     messages directly.
>
> b) If the messages are not fixed, I see no point in having the above
>     fixed messages at all.
>
> c) If the messages are not fixed, but you want to have default messages,
>     the messages do not belong in the uapi header at all. Hide them in
>     the kernel.
My intention was option C, wherein have a default message and the driver 
is free
to overwrite the default message string if required.
I agree in that case doesn't make sense having it on uapi, will move this
inside the driver.
>>>> +
>>>> +#define FAILURE_REASON(flag, reason) #reason,
>>>> +extern const char *drm_mode_atomic_failure_string[];
>>>> +#undef FAILURE_REASON
>>> Data is not an interface. Don't expose arrays like this. Who is even
>>> going to know what its size is? Again, uapi header, where does it point,
>>> what address space is it?
>>>
>> Sorry missed adding documentation for this. Will add in my next series.
> Documentation does not fix the issue that data is not an interface.
As pointed out above will move to option C, and will get rid of this 
failure messages
in the uapi.
>>>> +
>>>> +/**
>>>> + * drm_mode_atomic_err_code - struct to store the error code
>>>> + *
>>>> + * pointer to this struct will be stored in reserved variable of
>>>> + * struct drm_mode_atomic to report the failure cause to the user.
>>>> + *
>>>> + * @failure_flags: error codes defined in drm_atomic_failure.failure_flag
>>> Flags? As in a mask of multiple things? Is 64 going to be enough for
>>> everyone, all conditions in all drivers?
>> Should be more that sufficient, this is an enum.
> Then don't call it "flags".
Done!
>>> OTOH, what's the promise wrt multiple reasons? Practically all drivers
>>> bail out at the sight of first issue, and it's usually pretty much
>>> meaningless to continue to figure out *other* reasons after that.
>>>
>>> And this brings us to one of my main concerns on making this fly:
>>>
>>> You bail out on the first thing, but you can't expect all drivers to
>>> check stuff in the same order. It's not practical. So different drivers
>>> will likely return different reasons for virtually the same
>>> condition. So how is userspace going to handle that?
>> Most of the error check is in the drm-core and these are common across
>> the drivers.  Upon drivers sending driver specific error code, the
>> compositor may not be able to handle the error code. But in cases
>> required compositor changes can be added so as to handle them. In
>> general the generic error conditions that are met by compositor and
>> for which compositor can take corrective measurements are listed down
>> first.
> I think we're going to need a handful of error codes for starters, along
> with compositor changes that make meaningful and benefitial usage of the
> error codes.

Sure will narrow down the list in my next version.

Thanks and Regards,
Arun R Murthy
-------------------

[-- Attachment #2: Type: text/html, Size: 10892 bytes --]

Re: [PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

[Xaver Hugl]

> +#define DRM_MODE_ATOMIC_FAILURE_REASON \
> +       FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC capability not enabled") \
> +       FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
> +       FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy DRM_MODE_PAGE_FLIP_ASYNC not to be used in atomic ioctl") \
> +       FAILURE_REASON(DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY, "requesting page-flip event with TEST_ONLY") \
> +       FAILURE_REASON(DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET, "Need full modeset on this crtc") \
> +       FAILURE_REASON(DRM_MODE_ATOMIC_NEED_FULL_MODESET, "Need full modeset on all the connected crtc's") \
> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE, "Async flip not supported on this plane") \
> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED, "Modifier not supported on this plane with async flip") \
> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED, "No property change allowed when async flip is enabled")
As mentioned before, some of these errors are a bit too specific. We
don't need to have an enum value for every way the API can be used
wrongly - CAP_NOT_ENABLED, INVALID_FLAG, PAGE_FLIP_ASYNC and
MODIFIER_NOT_SUPPORTED should all just be one enum value for "invalid
API usage".
In general, there should only be enum values that the compositor
implementation can actually use on end-user systems. For further
information when debugging a broken compositor implementation, other
tools can be used instead, like drm debug logging or the returned
string.

> +#define FAILURE_REASON(flag, reason) flag,
> +typedef enum {
> +       DRM_MODE_ATOMIC_FAILURE_REASON
> +} drm_mode_atomic_failure_flag;
> +#undef FAILURE_REASON
> +
> +#define FAILURE_REASON(flag, reason) #reason,
> +extern const char *drm_mode_atomic_failure_string[];
> +#undef FAILURE_REASON
The intention for the string wasn't for the enum values to be paired
with a description of the enum - that belongs into documentation, not
uAPI.

The idea behind it was that drivers could add driver-specific
information in the string for compositors to log (only in commits
where failure isn't normally expected), so we have an easier time
debugging issues a user system experienced by looking at the
compositor logs. Sending the enum value again in string form isn't
useful.

- Xaver

Re: [PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

[Murthy, Arun R]

On 22-08-2025 21:44, Xaver Hugl wrote:
>> +#define DRM_MODE_ATOMIC_FAILURE_REASON \
>> +       FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC capability not enabled") \
>> +       FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
>> +       FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy DRM_MODE_PAGE_FLIP_ASYNC not to be used in atomic ioctl") \
>> +       FAILURE_REASON(DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY, "requesting page-flip event with TEST_ONLY") \
>> +       FAILURE_REASON(DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET, "Need full modeset on this crtc") \
>> +       FAILURE_REASON(DRM_MODE_ATOMIC_NEED_FULL_MODESET, "Need full modeset on all the connected crtc's") \
>> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE, "Async flip not supported on this plane") \
>> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED, "Modifier not supported on this plane with async flip") \
>> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED, "No property change allowed when async flip is enabled")
> As mentioned before, some of these errors are a bit too specific. We
> don't need to have an enum value for every way the API can be used
> wrongly - CAP_NOT_ENABLED, INVALID_FLAG, PAGE_FLIP_ASYNC and
> MODIFIER_NOT_SUPPORTED should all just be one enum value for "invalid
> API usage".
> In general, there should only be enum values that the compositor
> implementation can actually use on end-user systems. For further
> information when debugging a broken compositor implementation, other
> tools can be used instead, like drm debug logging or the returned
> string.
I have considered your comment in the last series and have removed 
driver specific errors.
Anyway will have a look again on this and will get back.
>> +#define FAILURE_REASON(flag, reason) flag,
>> +typedef enum {
>> +       DRM_MODE_ATOMIC_FAILURE_REASON
>> +} drm_mode_atomic_failure_flag;
>> +#undef FAILURE_REASON
>> +
>> +#define FAILURE_REASON(flag, reason) #reason,
>> +extern const char *drm_mode_atomic_failure_string[];
>> +#undef FAILURE_REASON
> The intention for the string wasn't for the enum values to be paired
> with a description of the enum - that belongs into documentation, not
> uAPI.
>
> The idea behind it was that drivers could add driver-specific
> information in the string for compositors to log (only in commits
> where failure isn't normally expected), so we have an easier time
> debugging issues a user system experienced by looking at the
> compositor logs. Sending the enum value again in string form isn't
> useful.

We are not sending enum value in string. Its just a single place where 
we have both enum and string. Upon user adding new error codes if both 
enum and string are at a single place it would be easy for the user. 
Hence adding both in a single place using X macros.

Its not mandatory to have a string for every enum, the string can be 
left empty if not required, or later in the driver user can overwrite 
the string as well.

Thanks and Regards,
Arun R Murthy
--------------------

> - Xaver

Re: [PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

[Jani Nikula]

On Sat, 23 Aug 2025, "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> On 22-08-2025 21:44, Xaver Hugl wrote:
>>> +#define DRM_MODE_ATOMIC_FAILURE_REASON \
>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC capability not enabled") \
>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy DRM_MODE_PAGE_FLIP_ASYNC not to be used in atomic ioctl") \
>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY, "requesting page-flip event with TEST_ONLY") \
>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET, "Need full modeset on this crtc") \
>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_NEED_FULL_MODESET, "Need full modeset on all the connected crtc's") \
>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE, "Async flip not supported on this plane") \
>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED, "Modifier not supported on this plane with async flip") \
>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED, "No property change allowed when async flip is enabled")
>> As mentioned before, some of these errors are a bit too specific. We
>> don't need to have an enum value for every way the API can be used
>> wrongly - CAP_NOT_ENABLED, INVALID_FLAG, PAGE_FLIP_ASYNC and
>> MODIFIER_NOT_SUPPORTED should all just be one enum value for "invalid
>> API usage".
>> In general, there should only be enum values that the compositor
>> implementation can actually use on end-user systems. For further
>> information when debugging a broken compositor implementation, other
>> tools can be used instead, like drm debug logging or the returned
>> string.
> I have considered your comment in the last series and have removed 
> driver specific errors.
> Anyway will have a look again on this and will get back.
>>> +#define FAILURE_REASON(flag, reason) flag,
>>> +typedef enum {
>>> +       DRM_MODE_ATOMIC_FAILURE_REASON
>>> +} drm_mode_atomic_failure_flag;
>>> +#undef FAILURE_REASON
>>> +
>>> +#define FAILURE_REASON(flag, reason) #reason,
>>> +extern const char *drm_mode_atomic_failure_string[];
>>> +#undef FAILURE_REASON
>> The intention for the string wasn't for the enum values to be paired
>> with a description of the enum - that belongs into documentation, not
>> uAPI.
>>
>> The idea behind it was that drivers could add driver-specific
>> information in the string for compositors to log (only in commits
>> where failure isn't normally expected), so we have an easier time
>> debugging issues a user system experienced by looking at the
>> compositor logs. Sending the enum value again in string form isn't
>> useful.
>
> We are not sending enum value in string. Its just a single place where 
> we have both enum and string. Upon user adding new error codes if both 
> enum and string are at a single place it would be easy for the user. 
> Hence adding both in a single place using X macros.
>
> Its not mandatory to have a string for every enum, the string can be 
> left empty if not required, or later in the driver user can overwrite 
> the string as well.

See my reply [1] about fixed vs. non-fixed error messages.

I believe Xaver is also saying we don't want the fixed error messages,
and especially not in a uapi header.

BR,
Jani.


[1] https://lore.kernel.org/r/419591dda7158b3d56c40aac0df86ca499202676@intel.com

-- 
Jani Nikula, Intel

Re: [PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

[Murthy, Arun R]

On 25-08-2025 15:17, Jani Nikula wrote:
> On Sat, 23 Aug 2025, "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
>> On 22-08-2025 21:44, Xaver Hugl wrote:
>>>> +#define DRM_MODE_ATOMIC_FAILURE_REASON \
>>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC capability not enabled") \
>>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
>>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy DRM_MODE_PAGE_FLIP_ASYNC not to be used in atomic ioctl") \
>>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY, "requesting page-flip event with TEST_ONLY") \
>>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET, "Need full modeset on this crtc") \
>>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_NEED_FULL_MODESET, "Need full modeset on all the connected crtc's") \
>>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE, "Async flip not supported on this plane") \
>>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED, "Modifier not supported on this plane with async flip") \
>>>> +       FAILURE_REASON(DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED, "No property change allowed when async flip is enabled")
>>> As mentioned before, some of these errors are a bit too specific. We
>>> don't need to have an enum value for every way the API can be used
>>> wrongly - CAP_NOT_ENABLED, INVALID_FLAG, PAGE_FLIP_ASYNC and
>>> MODIFIER_NOT_SUPPORTED should all just be one enum value for "invalid
>>> API usage".
>>> In general, there should only be enum values that the compositor
>>> implementation can actually use on end-user systems. For further
>>> information when debugging a broken compositor implementation, other
>>> tools can be used instead, like drm debug logging or the returned
>>> string.
>> I have considered your comment in the last series and have removed
>> driver specific errors.
>> Anyway will have a look again on this and will get back.
>>>> +#define FAILURE_REASON(flag, reason) flag,
>>>> +typedef enum {
>>>> +       DRM_MODE_ATOMIC_FAILURE_REASON
>>>> +} drm_mode_atomic_failure_flag;
>>>> +#undef FAILURE_REASON
>>>> +
>>>> +#define FAILURE_REASON(flag, reason) #reason,
>>>> +extern const char *drm_mode_atomic_failure_string[];
>>>> +#undef FAILURE_REASON
>>> The intention for the string wasn't for the enum values to be paired
>>> with a description of the enum - that belongs into documentation, not
>>> uAPI.
>>>
>>> The idea behind it was that drivers could add driver-specific
>>> information in the string for compositors to log (only in commits
>>> where failure isn't normally expected), so we have an easier time
>>> debugging issues a user system experienced by looking at the
>>> compositor logs. Sending the enum value again in string form isn't
>>> useful.
>> We are not sending enum value in string. Its just a single place where
>> we have both enum and string. Upon user adding new error codes if both
>> enum and string are at a single place it would be easy for the user.
>> Hence adding both in a single place using X macros.
>>
>> Its not mandatory to have a string for every enum, the string can be
>> left empty if not required, or later in the driver user can overwrite
>> the string as well.
> See my reply [1] about fixed vs. non-fixed error messages.
>
> I believe Xaver is also saying we don't want the fixed error messages,
> and especially not in a uapi header.
>
> BR,
> Jani.
>
>
> [1] https://lore.kernel.org/r/419591dda7158b3d56c40aac0df86ca499202676@intel.com
As pointed out in option C of [2] I also feel better to have a default 
message so that
  compositor can use it for logging.

Thanks and Regards,
Arun R Murthy
--------------------

[2] 
https://lore.kernel.org/all/419591dda7158b3d56c40aac0df86ca499202676@intel.com/

[PATCH v3 2/4] drm/atomic: Add error_code element in atomic_state

[Arun R Murthy]

Now that a proper error code will be returned to the user on any failure
in atomic_ioctl() via struct drm_mode_atomic, add a new element
error_code in the struct drm_atomic_state so as to hold the error code
during the atomic_check() and atomic_commit() phases.

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
 include/drm/drm_atomic.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 38636a593c9d98cadda85ccd67326cb152f0dd27..d380001b24b4223baa54dae6c3c43e19dfb1958d 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -524,6 +524,13 @@ struct drm_atomic_state {
 	 * commit without blocking.
 	 */
 	struct work_struct commit_work;
+
+	/* @error_code
+	 *
+	 * struct to convey user readable error to the user.
+	 * Error codes defined in enum drm_mode_atomic_failure_flags
+	 */
+	struct drm_mode_atomic_err_code *error_code;
 };
 
 void __drm_crtc_commit_free(struct kref *kref);

-- 
2.25.1

[PATCH v3 3/4] drm/atomic: Return user readable error in atomic_ioctl

[Arun R Murthy]

Add user readable error codes for failure cases in drm_atomic_ioctl() so
that user can decode the error code and take corrective measurements.

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
 drivers/gpu/drm/drm_atomic.c      |  6 ++++
 drivers/gpu/drm/drm_atomic_uapi.c | 60 ++++++++++++++++++++++++++++++++-------
 2 files changed, 56 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index cd15cf52f0c9144711da5879da57884674aea9e4..5f25e6d3cf6cf246f83a8c39450b410e97fe45bb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1513,6 +1513,9 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
 			if (drm_atomic_crtc_needs_modeset(new_crtc_state)) {
 				drm_dbg_atomic(dev, "[CRTC:%d:%s] requires full modeset\n",
 					       crtc->base.id, crtc->name);
+				state->error_code->failure_flags =
+					DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET;
+
 				return -EINVAL;
 			}
 		}
@@ -1537,8 +1540,11 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
 		drm_dbg_atomic(dev,
 			       "driver added CRTC to commit: requested 0x%x, affected 0x%0x\n",
 			       requested_crtc, affected_crtc);
+		state->error_code->failure_flags = DRM_MODE_ATOMIC_NEED_FULL_MODESET;
 		WARN(!state->allow_modeset, "adding CRTC not allowed without modesets: requested 0x%x, affected 0x%0x\n",
 		     requested_crtc, affected_crtc);
+
+		return -EINVAL;
 	}
 
 	return 0;
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index ecc73d52bfae41a7ef455a7e13649ec56c690b90..94eaf9c98eb4ac2455799f1416010d366e1b5bbc 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1058,6 +1058,9 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
 			ret = drm_atomic_crtc_get_property(crtc, crtc_state,
 							   prop, &old_val);
 			ret = drm_atomic_check_prop_changes(ret, old_val, prop_value, prop);
+			if (ret)
+				state->error_code->failure_flags =
+					DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED;
 			break;
 		}
 
@@ -1089,6 +1092,8 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
 
 			/* ask the driver if this non-primary plane is supported */
 			if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
+				state->error_code->failure_flags =
+					DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE;
 				ret = -EINVAL;
 
 				if (plane_funcs && plane_funcs->atomic_async_check)
@@ -1380,6 +1385,13 @@ set_async_flip(struct drm_atomic_state *state)
 	}
 }
 
+#define FAILURE_REASON(flag, reason) #reason,
+const char *drm_mode_atomic_failure_string[] = {
+	DRM_MODE_ATOMIC_FAILURE_REASON
+};
+
+#undef FAILURE_REASON
+
 int drm_mode_atomic_ioctl(struct drm_device *dev,
 			  void *data, struct drm_file *file_priv)
 {
@@ -1389,9 +1401,11 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	uint32_t __user *props_ptr = (uint32_t __user *)(unsigned long)(arg->props_ptr);
 	uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned long)(arg->prop_values_ptr);
 	unsigned int copied_objs, copied_props;
-	struct drm_atomic_state *state;
+	struct drm_atomic_state *state = NULL;
 	struct drm_modeset_acquire_ctx ctx;
 	struct drm_out_fence_state *fence_state;
+	struct drm_mode_atomic_err_code error_code;
+	struct drm_mode_atomic_err_code __user *error_code_ptr;
 	int ret = 0;
 	unsigned int i, j, num_fences;
 	bool async_flip = false;
@@ -1400,6 +1414,11 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
 		return -EOPNOTSUPP;
 
+	if (!arg->reserved)
+		drm_err(dev, "memory not allocated for drm_atomic error reporting\n");
+
+	memset(&error_code, 0, sizeof(struct drm_mode_atomic_err_code));
+
 	/* disallow for userspace that has not enabled atomic cap (even
 	 * though this may be a bit overkill, since legacy userspace
 	 * wouldn't know how to call this ioctl)
@@ -1407,24 +1426,25 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	if (!file_priv->atomic) {
 		drm_dbg_atomic(dev,
 			       "commit failed: atomic cap not enabled\n");
-		return -EINVAL;
+		error_code.failure_flags = DRM_MODE_ATOMIC_CAP_NOT_ENABLED;
+		ret = -EINVAL;
+		goto out;
 	}
 
 	if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS) {
 		drm_dbg_atomic(dev, "commit failed: invalid flag\n");
-		return -EINVAL;
-	}
-
-	if (arg->reserved) {
-		drm_dbg_atomic(dev, "commit failed: reserved field set\n");
-		return -EINVAL;
+		error_code.failure_flags = DRM_MODE_ATOMIC_INVALID_FLAG;
+		ret = -EINVAL;
+		goto out;
 	}
 
 	if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) {
 		if (!dev->mode_config.async_page_flip) {
 			drm_dbg_atomic(dev,
 				       "commit failed: DRM_MODE_PAGE_FLIP_ASYNC not supported\n");
-			return -EINVAL;
+			error_code.failure_flags = DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC;
+			ret = -EINVAL;
+			goto out;
 		}
 
 		async_flip = true;
@@ -1435,7 +1455,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 			(arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) {
 		drm_dbg_atomic(dev,
 			       "commit failed: page-flip event requested with test-only commit\n");
-		return -EINVAL;
+		error_code.failure_flags = DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY;
+		ret = -EINVAL;
+		goto out;
 	}
 
 	state = drm_atomic_state_alloc(dev);
@@ -1446,6 +1468,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	state->acquire_ctx = &ctx;
 	state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
 
+	state->error_code = &error_code;
+
 retry:
 	copied_objs = 0;
 	copied_props = 0;
@@ -1542,6 +1566,22 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	}
 
 out:
+	/* update the error code if any error to allow user handling it */
+	if (ret < 0 && arg->reserved) {
+		error_code_ptr = (struct drm_mode_atomic_err_code __user *)
+				 (unsigned long)arg->reserved;
+
+		strscpy_pad(error_code.failure_string,
+			    drm_mode_atomic_failure_string[error_code.failure_flags],
+			    sizeof(error_code.failure_string));
+
+		if (copy_to_user(error_code_ptr, &error_code, sizeof(error_code)))
+			return -EFAULT;
+	}
+
+	if (!state)
+		return ret;
+
 	complete_signaling(dev, state, fence_state, num_fences, !ret);
 
 	if (ret == -EDEADLK) {

-- 
2.25.1

Re: [PATCH v3 3/4] drm/atomic: Return user readable error in atomic_ioctl

[Jani Nikula]

On Fri, 22 Aug 2025, Arun R Murthy <arun.r.murthy@intel.com> wrote:
> Add user readable error codes for failure cases in drm_atomic_ioctl() so
> that user can decode the error code and take corrective measurements.
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
>  drivers/gpu/drm/drm_atomic.c      |  6 ++++
>  drivers/gpu/drm/drm_atomic_uapi.c | 60 ++++++++++++++++++++++++++++++++-------
>  2 files changed, 56 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index cd15cf52f0c9144711da5879da57884674aea9e4..5f25e6d3cf6cf246f83a8c39450b410e97fe45bb 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1513,6 +1513,9 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
>  			if (drm_atomic_crtc_needs_modeset(new_crtc_state)) {
>  				drm_dbg_atomic(dev, "[CRTC:%d:%s] requires full modeset\n",
>  					       crtc->base.id, crtc->name);
> +				state->error_code->failure_flags =
> +					DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET;

It says flags, implying multiple, but you're just adding one there
anyway. Just like it was a regular enum.

> +
>  				return -EINVAL;
>  			}
>  		}
> @@ -1537,8 +1540,11 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
>  		drm_dbg_atomic(dev,
>  			       "driver added CRTC to commit: requested 0x%x, affected 0x%0x\n",
>  			       requested_crtc, affected_crtc);
> +		state->error_code->failure_flags = DRM_MODE_ATOMIC_NEED_FULL_MODESET;
>  		WARN(!state->allow_modeset, "adding CRTC not allowed without modesets: requested 0x%x, affected 0x%0x\n",
>  		     requested_crtc, affected_crtc);
> +
> +		return -EINVAL;

This changes behaviour.

>  	}
>  
>  	return 0;
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index ecc73d52bfae41a7ef455a7e13649ec56c690b90..94eaf9c98eb4ac2455799f1416010d366e1b5bbc 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1058,6 +1058,9 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
>  			ret = drm_atomic_crtc_get_property(crtc, crtc_state,
>  							   prop, &old_val);
>  			ret = drm_atomic_check_prop_changes(ret, old_val, prop_value, prop);
> +			if (ret)
> +				state->error_code->failure_flags =
> +					DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED;
>  			break;
>  		}
>  
> @@ -1089,6 +1092,8 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
>  
>  			/* ask the driver if this non-primary plane is supported */
>  			if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
> +				state->error_code->failure_flags =
> +					DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE;
>  				ret = -EINVAL;
>  
>  				if (plane_funcs && plane_funcs->atomic_async_check)
> @@ -1380,6 +1385,13 @@ set_async_flip(struct drm_atomic_state *state)
>  	}
>  }
>  
> +#define FAILURE_REASON(flag, reason) #reason,
> +const char *drm_mode_atomic_failure_string[] = {
> +	DRM_MODE_ATOMIC_FAILURE_REASON
> +};
> +
> +#undef FAILURE_REASON
> +
>  int drm_mode_atomic_ioctl(struct drm_device *dev,
>  			  void *data, struct drm_file *file_priv)
>  {
> @@ -1389,9 +1401,11 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>  	uint32_t __user *props_ptr = (uint32_t __user *)(unsigned long)(arg->props_ptr);
>  	uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned long)(arg->prop_values_ptr);
>  	unsigned int copied_objs, copied_props;
> -	struct drm_atomic_state *state;
> +	struct drm_atomic_state *state = NULL;
>  	struct drm_modeset_acquire_ctx ctx;
>  	struct drm_out_fence_state *fence_state;
> +	struct drm_mode_atomic_err_code error_code;
> +	struct drm_mode_atomic_err_code __user *error_code_ptr;
>  	int ret = 0;
>  	unsigned int i, j, num_fences;
>  	bool async_flip = false;
> @@ -1400,6 +1414,11 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>  	if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
>  		return -EOPNOTSUPP;
>  
> +	if (!arg->reserved)
> +		drm_err(dev, "memory not allocated for drm_atomic error reporting\n");

This right here makes me suspect you never really tried this with your
regular desktop environment.

> +
> +	memset(&error_code, 0, sizeof(struct drm_mode_atomic_err_code));
> +
>  	/* disallow for userspace that has not enabled atomic cap (even
>  	 * though this may be a bit overkill, since legacy userspace
>  	 * wouldn't know how to call this ioctl)
> @@ -1407,24 +1426,25 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>  	if (!file_priv->atomic) {
>  		drm_dbg_atomic(dev,
>  			       "commit failed: atomic cap not enabled\n");
> -		return -EINVAL;
> +		error_code.failure_flags = DRM_MODE_ATOMIC_CAP_NOT_ENABLED;
> +		ret = -EINVAL;
> +		goto out;
>  	}
>  
>  	if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS) {
>  		drm_dbg_atomic(dev, "commit failed: invalid flag\n");
> -		return -EINVAL;
> -	}
> -
> -	if (arg->reserved) {
> -		drm_dbg_atomic(dev, "commit failed: reserved field set\n");
> -		return -EINVAL;
> +		error_code.failure_flags = DRM_MODE_ATOMIC_INVALID_FLAG;
> +		ret = -EINVAL;
> +		goto out;
>  	}
>  
>  	if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) {
>  		if (!dev->mode_config.async_page_flip) {
>  			drm_dbg_atomic(dev,
>  				       "commit failed: DRM_MODE_PAGE_FLIP_ASYNC not supported\n");
> -			return -EINVAL;
> +			error_code.failure_flags = DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC;
> +			ret = -EINVAL;
> +			goto out;
>  		}
>  
>  		async_flip = true;
> @@ -1435,7 +1455,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>  			(arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) {
>  		drm_dbg_atomic(dev,
>  			       "commit failed: page-flip event requested with test-only commit\n");
> -		return -EINVAL;
> +		error_code.failure_flags = DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY;
> +		ret = -EINVAL;
> +		goto out;
>  	}
>  
>  	state = drm_atomic_state_alloc(dev);
> @@ -1446,6 +1468,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>  	state->acquire_ctx = &ctx;
>  	state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
>  
> +	state->error_code = &error_code;
> +
>  retry:
>  	copied_objs = 0;
>  	copied_props = 0;
> @@ -1542,6 +1566,22 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>  	}
>  
>  out:
> +	/* update the error code if any error to allow user handling it */
> +	if (ret < 0 && arg->reserved) {
> +		error_code_ptr = (struct drm_mode_atomic_err_code __user *)
> +				 (unsigned long)arg->reserved;
> +
> +		strscpy_pad(error_code.failure_string,
> +			    drm_mode_atomic_failure_string[error_code.failure_flags],
> +			    sizeof(error_code.failure_string));
> +
> +		if (copy_to_user(error_code_ptr, &error_code, sizeof(error_code)))
> +			return -EFAULT;
> +	}
> +
> +	if (!state)
> +		return ret;
> +
>  	complete_signaling(dev, state, fence_state, num_fences, !ret);
>  
>  	if (ret == -EDEADLK) {

-- 
Jani Nikula, Intel

Re: [PATCH v3 3/4] drm/atomic: Return user readable error in atomic_ioctl

[Murthy, Arun R]

On 22-08-2025 16:20, Jani Nikula wrote:
> On Fri, 22 Aug 2025, Arun R Murthy <arun.r.murthy@intel.com> wrote:
>> Add user readable error codes for failure cases in drm_atomic_ioctl() so
>> that user can decode the error code and take corrective measurements.
>>
>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>> ---
>>   drivers/gpu/drm/drm_atomic.c      |  6 ++++
>>   drivers/gpu/drm/drm_atomic_uapi.c | 60 ++++++++++++++++++++++++++++++++-------
>>   2 files changed, 56 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index cd15cf52f0c9144711da5879da57884674aea9e4..5f25e6d3cf6cf246f83a8c39450b410e97fe45bb 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -1513,6 +1513,9 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
>>   			if (drm_atomic_crtc_needs_modeset(new_crtc_state)) {
>>   				drm_dbg_atomic(dev, "[CRTC:%d:%s] requires full modeset\n",
>>   					       crtc->base.id, crtc->name);
>> +				state->error_code->failure_flags =
>> +					DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET;
> It says flags, implying multiple, but you're just adding one there
> anyway. Just like it was a regular enum.
Yes its a enum!
>
>> +
>>   				return -EINVAL;
>>   			}
>>   		}
>> @@ -1537,8 +1540,11 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
>>   		drm_dbg_atomic(dev,
>>   			       "driver added CRTC to commit: requested 0x%x, affected 0x%0x\n",
>>   			       requested_crtc, affected_crtc);
>> +		state->error_code->failure_flags = DRM_MODE_ATOMIC_NEED_FULL_MODESET;
>>   		WARN(!state->allow_modeset, "adding CRTC not allowed without modesets: requested 0x%x, affected 0x%0x\n",
>>   		     requested_crtc, affected_crtc);
>> +
>> +		return -EINVAL;
> This changes behaviour.
Will get it corrected in the next version!
>
>>   	}
>>   
>>   	return 0;
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
>> index ecc73d52bfae41a7ef455a7e13649ec56c690b90..94eaf9c98eb4ac2455799f1416010d366e1b5bbc 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -1058,6 +1058,9 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
>>   			ret = drm_atomic_crtc_get_property(crtc, crtc_state,
>>   							   prop, &old_val);
>>   			ret = drm_atomic_check_prop_changes(ret, old_val, prop_value, prop);
>> +			if (ret)
>> +				state->error_code->failure_flags =
>> +					DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED;
>>   			break;
>>   		}
>>   
>> @@ -1089,6 +1092,8 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
>>   
>>   			/* ask the driver if this non-primary plane is supported */
>>   			if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
>> +				state->error_code->failure_flags =
>> +					DRM_MODE_ATOMIC_ASYNC_NOT_SUP_PLANE;
>>   				ret = -EINVAL;
>>   
>>   				if (plane_funcs && plane_funcs->atomic_async_check)
>> @@ -1380,6 +1385,13 @@ set_async_flip(struct drm_atomic_state *state)
>>   	}
>>   }
>>   
>> +#define FAILURE_REASON(flag, reason) #reason,
>> +const char *drm_mode_atomic_failure_string[] = {
>> +	DRM_MODE_ATOMIC_FAILURE_REASON
>> +};
>> +
>> +#undef FAILURE_REASON
>> +
>>   int drm_mode_atomic_ioctl(struct drm_device *dev,
>>   			  void *data, struct drm_file *file_priv)
>>   {
>> @@ -1389,9 +1401,11 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>>   	uint32_t __user *props_ptr = (uint32_t __user *)(unsigned long)(arg->props_ptr);
>>   	uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned long)(arg->prop_values_ptr);
>>   	unsigned int copied_objs, copied_props;
>> -	struct drm_atomic_state *state;
>> +	struct drm_atomic_state *state = NULL;
>>   	struct drm_modeset_acquire_ctx ctx;
>>   	struct drm_out_fence_state *fence_state;
>> +	struct drm_mode_atomic_err_code error_code;
>> +	struct drm_mode_atomic_err_code __user *error_code_ptr;
>>   	int ret = 0;
>>   	unsigned int i, j, num_fences;
>>   	bool async_flip = false;
>> @@ -1400,6 +1414,11 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>>   	if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
>>   		return -EOPNOTSUPP;
>>   
>> +	if (!arg->reserved)
>> +		drm_err(dev, "memory not allocated for drm_atomic error reporting\n");
> This right here makes me suspect you never really tried this with your
> regular desktop environment.
>
>> +
>> +	memset(&error_code, 0, sizeof(struct drm_mode_atomic_err_code));
>> +
>>   	/* disallow for userspace that has not enabled atomic cap (even
>>   	 * though this may be a bit overkill, since legacy userspace
>>   	 * wouldn't know how to call this ioctl)
>> @@ -1407,24 +1426,25 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>>   	if (!file_priv->atomic) {
>>   		drm_dbg_atomic(dev,
>>   			       "commit failed: atomic cap not enabled\n");
>> -		return -EINVAL;
>> +		error_code.failure_flags = DRM_MODE_ATOMIC_CAP_NOT_ENABLED;
>> +		ret = -EINVAL;
>> +		goto out;
>>   	}
>>   
>>   	if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS) {
>>   		drm_dbg_atomic(dev, "commit failed: invalid flag\n");
>> -		return -EINVAL;
>> -	}
>> -
>> -	if (arg->reserved) {
>> -		drm_dbg_atomic(dev, "commit failed: reserved field set\n");
>> -		return -EINVAL;
>> +		error_code.failure_flags = DRM_MODE_ATOMIC_INVALID_FLAG;
>> +		ret = -EINVAL;
>> +		goto out;
>>   	}
>>   
>>   	if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) {
>>   		if (!dev->mode_config.async_page_flip) {
>>   			drm_dbg_atomic(dev,
>>   				       "commit failed: DRM_MODE_PAGE_FLIP_ASYNC not supported\n");
>> -			return -EINVAL;
>> +			error_code.failure_flags = DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC;
>> +			ret = -EINVAL;
>> +			goto out;
>>   		}
>>   
>>   		async_flip = true;
>> @@ -1435,7 +1455,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>>   			(arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) {
>>   		drm_dbg_atomic(dev,
>>   			       "commit failed: page-flip event requested with test-only commit\n");
>> -		return -EINVAL;
>> +		error_code.failure_flags = DRM_MODE_ATOMIC_FLIP_EVENT_WITH_CHECKONLY;
>> +		ret = -EINVAL;
>> +		goto out;
>>   	}
>>   
>>   	state = drm_atomic_state_alloc(dev);
>> @@ -1446,6 +1468,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>>   	state->acquire_ctx = &ctx;
>>   	state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
>>   
>> +	state->error_code = &error_code;
>> +
>>   retry:
>>   	copied_objs = 0;
>>   	copied_props = 0;
>> @@ -1542,6 +1566,22 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>>   	}
>>   
>>   out:
>> +	/* update the error code if any error to allow user handling it */
>> +	if (ret < 0 && arg->reserved) {
>> +		error_code_ptr = (struct drm_mode_atomic_err_code __user *)
>> +				 (unsigned long)arg->reserved;
>> +
>> +		strscpy_pad(error_code.failure_string,
>> +			    drm_mode_atomic_failure_string[error_code.failure_flags],
>> +			    sizeof(error_code.failure_string));
>> +
>> +		if (copy_to_user(error_code_ptr, &error_code, sizeof(error_code)))
>> +			return -EFAULT;
>> +	}
>> +
>> +	if (!state)
>> +		return ret;
>> +
>>   	complete_signaling(dev, state, fence_state, num_fences, !ret);
>>   
>>   	if (ret == -EDEADLK) {

[PATCH v3 4/4] drm/i915/display: Error codes for async flip failures

[Arun R Murthy]

For failures in async flip atomic check/commit path return user readable
error codes in struct drm_atomic_state.

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
 drivers/gpu/drm/i915/display/intel_display.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index c1a3a95c65f0b66c24ddd64f47dfdc67bbde86c9..5e23f4fc747bd01fa05eba63661bf7279b083317 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5950,6 +5950,7 @@ static int intel_async_flip_check_uapi(struct intel_atomic_state *state,
 		drm_dbg_kms(display->drm,
 			    "[CRTC:%d:%s] modeset required\n",
 			    crtc->base.base.id, crtc->base.name);
+		state->base.error_code->failure_flags = DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET;
 		return -EINVAL;
 	}
 
@@ -6019,6 +6020,7 @@ static int intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
 		drm_dbg_kms(display->drm,
 			    "[CRTC:%d:%s] modeset required\n",
 			    crtc->base.base.id, crtc->base.name);
+		state->base.error_code->failure_flags = DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET;
 		return -EINVAL;
 	}
 
@@ -6061,6 +6063,8 @@ static int intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
 				    plane->base.base.id, plane->base.name,
 				    &new_plane_state->hw.fb->format->format,
 				    new_plane_state->hw.fb->modifier);
+			state->base.error_code->failure_flags =
+				DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED;
 			return -EINVAL;
 		}
 

-- 
2.25.1

Re: [PATCH v3 4/4] drm/i915/display: Error codes for async flip failures

[Maarten Lankhorst]

Hey,

I'm not entirely sold on the design, it's way more complicated than it should be, it should be trivial to add any amount of error messages.

Replace return -EINVAL; with return drm_atomic_error_einval(state, class, "string");
Where class may be an enum, but in a way more generic way than currently specified, for example "invalid use of api", "requires modeset", "invalid arguments", "driver limitations", "async flip not possible".

The drm_atomic_error_einval() would set class and str as appropriate, and then return -EINVAL.

That's probably all we should need here.

Kind regards,
~Maarten

Den 2025-08-22 kl. 09:00, skrev Arun R Murthy:
> For failures in async flip atomic check/commit path return user readable
> error codes in struct drm_atomic_state.
> 
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index c1a3a95c65f0b66c24ddd64f47dfdc67bbde86c9..5e23f4fc747bd01fa05eba63661bf7279b083317 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5950,6 +5950,7 @@ static int intel_async_flip_check_uapi(struct intel_atomic_state *state,
>  		drm_dbg_kms(display->drm,
>  			    "[CRTC:%d:%s] modeset required\n",
>  			    crtc->base.base.id, crtc->base.name);
> +		state->base.error_code->failure_flags = DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET;
>  		return -EINVAL;
>  	}
>  
> @@ -6019,6 +6020,7 @@ static int intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
>  		drm_dbg_kms(display->drm,
>  			    "[CRTC:%d:%s] modeset required\n",
>  			    crtc->base.base.id, crtc->base.name);
> +		state->base.error_code->failure_flags = DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET;
>  		return -EINVAL;
>  	}
>  
> @@ -6061,6 +6063,8 @@ static int intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
>  				    plane->base.base.id, plane->base.name,
>  				    &new_plane_state->hw.fb->format->format,
>  				    new_plane_state->hw.fb->modifier);
> +			state->base.error_code->failure_flags =
> +				DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED;
>  			return -EINVAL;
>  		}
>  
> 

Re: [PATCH v3 4/4] drm/i915/display: Error codes for async flip failures

[Jani Nikula]

On Fri, 22 Aug 2025, Maarten Lankhorst <maarten.lankhorst@linux.intel.com> wrote:
> Hey,
>
> I'm not entirely sold on the design, it's way more complicated than it
> should be, it should be trivial to add any amount of error messages.

If we add error messages, how do we ensure the error messages themselves
never become part of UAPI? It doesn't take much for someone in userspace
to start doing strcmp on them.

> Replace return -EINVAL; with return drm_atomic_error_einval(state, class, "string");

Yeah, much cleaner. And if we go this route, then maybe make it printf
style to avoid callers having to clumsily fill a buffer first.

> Where class may be an enum, but in a way more generic way than
> currently specified, for example "invalid use of api", "requires
> modeset", "invalid arguments", "driver limitations", "async flip not
> possible".

That's also easier for userspace to deal with than a plethora of
flags. I guess the goals were more ambitious wrt precision/granularity,
but is that achievable?

BR,
Jani.

> The drm_atomic_error_einval() would set class and str as appropriate,
> and then return -EINVAL.
>
> That's probably all we should need here.
>
> Kind regards,
> ~Maarten
>
> Den 2025-08-22 kl. 09:00, skrev Arun R Murthy:
>> For failures in async flip atomic check/commit path return user readable
>> error codes in struct drm_atomic_state.
>> 
>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>> ---
>>  drivers/gpu/drm/i915/display/intel_display.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
>> index c1a3a95c65f0b66c24ddd64f47dfdc67bbde86c9..5e23f4fc747bd01fa05eba63661bf7279b083317 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -5950,6 +5950,7 @@ static int intel_async_flip_check_uapi(struct intel_atomic_state *state,
>>  		drm_dbg_kms(display->drm,
>>  			    "[CRTC:%d:%s] modeset required\n",
>>  			    crtc->base.base.id, crtc->base.name);
>> +		state->base.error_code->failure_flags = DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET;
>>  		return -EINVAL;
>>  	}
>>  
>> @@ -6019,6 +6020,7 @@ static int intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
>>  		drm_dbg_kms(display->drm,
>>  			    "[CRTC:%d:%s] modeset required\n",
>>  			    crtc->base.base.id, crtc->base.name);
>> +		state->base.error_code->failure_flags = DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET;
>>  		return -EINVAL;
>>  	}
>>  
>> @@ -6061,6 +6063,8 @@ static int intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
>>  				    plane->base.base.id, plane->base.name,
>>  				    &new_plane_state->hw.fb->format->format,
>>  				    new_plane_state->hw.fb->modifier);
>> +			state->base.error_code->failure_flags =
>> +				DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED;
>>  			return -EINVAL;
>>  		}
>>  
>> 
>

-- 
Jani Nikula, Intel

Re: [PATCH v3 4/4] drm/i915/display: Error codes for async flip failures

[Murthy, Arun R]

On 22-08-2025 17:01, Maarten Lankhorst wrote:
> Hey,
>
> I'm not entirely sold on the design, it's way more complicated than it should be, it should be trivial to add any amount of error messages.
>
> Replace return -EINVAL; with return drm_atomic_error_einval(state, class, "string");
> Where class may be an enum, but in a way more generic way than currently specified, for example "invalid use of api", "requires modeset", "invalid arguments", "driver limitations", "async flip not possible".
>
> The drm_atomic_error_einval() would set class and str as appropriate, and then return -EINVAL.
Looks good to me, but again this state, string will have to be filled to 
the struct and the address of the struct to be sent in the reserved 
field to the user.
So background for choosing this struct [1]

> That's probably all we should need here.
>
> Kind regards,
> ~Maarten
>
> Den 2025-08-22 kl. 09:00, skrev Arun R Murthy:
>> For failures in async flip atomic check/commit path return user readable
>> error codes in struct drm_atomic_state.
>>
>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>> ---
>>   drivers/gpu/drm/i915/display/intel_display.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
>> index c1a3a95c65f0b66c24ddd64f47dfdc67bbde86c9..5e23f4fc747bd01fa05eba63661bf7279b083317 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -5950,6 +5950,7 @@ static int intel_async_flip_check_uapi(struct intel_atomic_state *state,
>>   		drm_dbg_kms(display->drm,
>>   			    "[CRTC:%d:%s] modeset required\n",
>>   			    crtc->base.base.id, crtc->base.name);
>> +		state->base.error_code->failure_flags = DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET;
>>   		return -EINVAL;
>>   	}
>>   
>> @@ -6019,6 +6020,7 @@ static int intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
>>   		drm_dbg_kms(display->drm,
>>   			    "[CRTC:%d:%s] modeset required\n",
>>   			    crtc->base.base.id, crtc->base.name);
>> +		state->base.error_code->failure_flags = DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET;
>>   		return -EINVAL;
>>   	}
>>   
>> @@ -6061,6 +6063,8 @@ static int intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
>>   				    plane->base.base.id, plane->base.name,
>>   				    &new_plane_state->hw.fb->format->format,
>>   				    new_plane_state->hw.fb->modifier);
>> +			state->base.error_code->failure_flags =
>> +				DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED;
>>   			return -EINVAL;
>>   		}
>>   
>>
Thanks and Regards,
Arun R Murthy
-------------------
[1] https://hackmd.io/f3bDn3kyRUalLn4LbMfCVQ#Commit-Failure-Feedback

✗ i915.CI.BAT: failure for User readable error codes on atomic_ioctl failure (rev2)

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 14704 bytes --]

== Series Details ==

Series: User readable error codes on atomic_ioctl failure (rev2)
URL   : https://patchwork.freedesktop.org/series/152275/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_17049 -> Patchwork_152275v2
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_152275v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_152275v2, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/index.html

Participating hosts (43 -> 43)
------------------------------

  Additional (1): fi-glk-j4005 
  Missing    (1): fi-snb-2520m 

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_152275v2:

### IGT changes ###

#### Possible regressions ####

  * igt@kms_busy@basic:
    - bat-adlp-6:         [PASS][1] -> [ABORT][2] +1 other test abort
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-adlp-6/igt@kms_busy@basic.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-adlp-6/igt@kms_busy@basic.html

  * igt@kms_busy@basic@flip:
    - fi-cfl-8700k:       [PASS][3] -> [DMESG-WARN][4] +8 other tests dmesg-warn
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/fi-cfl-8700k/igt@kms_busy@basic@flip.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-cfl-8700k/igt@kms_busy@basic@flip.html
    - bat-dg2-14:         [PASS][5] -> [ABORT][6] +1 other test abort
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-dg2-14/igt@kms_busy@basic@flip.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-dg2-14/igt@kms_busy@basic@flip.html
    - fi-elk-e7500:       [PASS][7] -> [DMESG-WARN][8] +10 other tests dmesg-warn
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/fi-elk-e7500/igt@kms_busy@basic@flip.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-elk-e7500/igt@kms_busy@basic@flip.html
    - bat-mtlp-9:         [PASS][9] -> [ABORT][10] +1 other test abort
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-mtlp-9/igt@kms_busy@basic@flip.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-mtlp-9/igt@kms_busy@basic@flip.html
    - bat-rpls-4:         [PASS][11] -> [ABORT][12] +1 other test abort
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-rpls-4/igt@kms_busy@basic@flip.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-rpls-4/igt@kms_busy@basic@flip.html
    - fi-cfl-8109u:       [PASS][13] -> [ABORT][14] +1 other test abort
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/fi-cfl-8109u/igt@kms_busy@basic@flip.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-cfl-8109u/igt@kms_busy@basic@flip.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
    - fi-hsw-4770:        [PASS][15] -> [DMESG-WARN][16] +10 other tests dmesg-warn
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/fi-hsw-4770/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-hsw-4770/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
    - bat-mtlp-8:         [PASS][17] -> [DMESG-WARN][18] +10 other tests dmesg-warn
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-mtlp-8/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-mtlp-8/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
    - bat-adls-6:         [PASS][19] -> [DMESG-WARN][20] +8 other tests dmesg-warn
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-adls-6/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-adls-6/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
    - bat-arlh-3:         [PASS][21] -> [DMESG-WARN][22] +10 other tests dmesg-warn
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-arlh-3/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-arlh-3/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
    - bat-dg1-7:          [PASS][23] -> [DMESG-WARN][24] +8 other tests dmesg-warn
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-dg1-7/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-dg1-7/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
    - fi-glk-j4005:       NOTRUN -> [DMESG-WARN][25] +8 other tests dmesg-warn
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-glk-j4005/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
    - bat-adlp-9:         [PASS][26] -> [DMESG-WARN][27] +8 other tests dmesg-warn
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-adlp-9/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-adlp-9/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
    - bat-twl-1:          [PASS][28] -> [DMESG-WARN][29] +10 other tests dmesg-warn
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-twl-1/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-twl-1/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
    - bat-apl-1:          [PASS][30] -> [DMESG-WARN][31] +8 other tests dmesg-warn
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-apl-1/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-apl-1/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
    - fi-skl-6600u:       [PASS][32] -> [DMESG-WARN][33] +10 other tests dmesg-warn
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/fi-skl-6600u/igt@kms_cursor_legacy@basic-flip-after-cursor-legacy.html
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-skl-6600u/igt@kms_cursor_legacy@basic-flip-after-cursor-legacy.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
    - bat-arls-6:         [PASS][34] -> [DMESG-WARN][35] +8 other tests dmesg-warn
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-arls-6/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-arls-6/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
    - fi-kbl-7567u:       [PASS][36] -> [DMESG-WARN][37] +8 other tests dmesg-warn
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/fi-kbl-7567u/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-kbl-7567u/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
    - fi-cfl-guc:         [PASS][38] -> [DMESG-WARN][39] +8 other tests dmesg-warn
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/fi-cfl-guc/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-cfl-guc/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
    - bat-twl-2:          [PASS][40] -> [DMESG-WARN][41] +10 other tests dmesg-warn
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-twl-2/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-twl-2/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
    - bat-dg2-11:         [PASS][42] -> [DMESG-WARN][43] +8 other tests dmesg-warn
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-dg2-11/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-dg2-11/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
    - fi-ivb-3770:        [PASS][44] -> [DMESG-WARN][45] +10 other tests dmesg-warn
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/fi-ivb-3770/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-ivb-3770/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
    - bat-dg2-8:          [PASS][46] -> [DMESG-WARN][47] +13 other tests dmesg-warn
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-dg2-8/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-dg2-8/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
    - fi-bsw-n3050:       [PASS][48] -> [DMESG-WARN][49] +10 other tests dmesg-warn
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
    - bat-arls-5:         [PASS][50] -> [DMESG-WARN][51] +8 other tests dmesg-warn
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-arls-5/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-arls-5/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
    - fi-ilk-650:         [PASS][52] -> [DMESG-WARN][53] +10 other tests dmesg-warn
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/fi-ilk-650/igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-ilk-650/igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size.html
    - fi-tgl-1115g4:      [PASS][54] -> [DMESG-WARN][55] +8 other tests dmesg-warn
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/fi-tgl-1115g4/igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-tgl-1115g4/igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size.html

  * igt@kms_dsc@dsc-basic@pipe-a-dp-1:
    - bat-dg2-9:          [PASS][56] -> [DMESG-WARN][57] +13 other tests dmesg-warn
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-dg2-9/igt@kms_dsc@dsc-basic@pipe-a-dp-1.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-dg2-9/igt@kms_dsc@dsc-basic@pipe-a-dp-1.html

  * igt@kms_flip@basic-flip-vs-dpms:
    - fi-glk-j4005:       NOTRUN -> [ABORT][58] +1 other test abort
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-glk-j4005/igt@kms_flip@basic-flip-vs-dpms.html

  * igt@kms_pm_backlight@basic-brightness@edp-1:
    - bat-jsl-1:          [PASS][59] -> [DMESG-WARN][60] +10 other tests dmesg-warn
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-jsl-1/igt@kms_pm_backlight@basic-brightness@edp-1.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-jsl-1/igt@kms_pm_backlight@basic-brightness@edp-1.html
    - bat-rplp-1:         [PASS][61] -> [DMESG-WARN][62] +10 other tests dmesg-warn
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-rplp-1/igt@kms_pm_backlight@basic-brightness@edp-1.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-rplp-1/igt@kms_pm_backlight@basic-brightness@edp-1.html

  
Known issues
------------

  Here are the changes found in Patchwork_152275v2 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_huc_copy@huc-copy:
    - fi-glk-j4005:       NOTRUN -> [SKIP][63] ([i915#2190])
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-glk-j4005/igt@gem_huc_copy@huc-copy.html

  * igt@i915_selftest@live@workarounds:
    - bat-dg2-9:          [PASS][64] -> [DMESG-FAIL][65] ([i915#12061]) +1 other test dmesg-fail
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-dg2-9/igt@i915_selftest@live@workarounds.html
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-dg2-9/igt@i915_selftest@live@workarounds.html

  * igt@intel_hwmon@hwmon-read:
    - fi-glk-j4005:       NOTRUN -> [SKIP][66] +4 other tests skip
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/fi-glk-j4005/igt@intel_hwmon@hwmon-read.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@workarounds:
    - bat-arlh-3:         [DMESG-FAIL][67] ([i915#12061]) -> [PASS][68] +1 other test pass
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-arlh-3/igt@i915_selftest@live@workarounds.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-arlh-3/igt@i915_selftest@live@workarounds.html
    - bat-arls-5:         [DMESG-FAIL][69] ([i915#12061]) -> [PASS][70] +1 other test pass
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-arls-5/igt@i915_selftest@live@workarounds.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-arls-5/igt@i915_selftest@live@workarounds.html
    - bat-mtlp-6:         [DMESG-FAIL][71] ([i915#12061]) -> [PASS][72] +1 other test pass
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17049/bat-mtlp-6/igt@i915_selftest@live@workarounds.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/bat-mtlp-6/igt@i915_selftest@live@workarounds.html

  
  [i915#12061]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12061
  [i915#2190]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/2190


Build changes
-------------

  * Linux: CI_DRM_17049 -> Patchwork_152275v2

  CI-20190529: 20190529
  CI_DRM_17049: cca87ca63e2f5b8a785dc59c23e526987530b27f @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_8503: 8503
  Patchwork_152275v2: cca87ca63e2f5b8a785dc59c23e526987530b27f @ git://anongit.freedesktop.org/gfx-ci/linux

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v2/index.html

[-- Attachment #2: Type: text/html, Size: 16016 bytes --]