[PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Arun R Murthy]

EDITME: Imported from f20260210-atomic-v9-5-525c88fd2402@intel.com
        Please review before sending.

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.

User will have to check for the capability
DRM_CAP_ATOMIC_ERROR_REPORTING before using this feature so as to ensure
that the driver supports failure reporting.

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

TODO: Once the series is merged the element 'reserved' used for sending
the failure code in struct drm_mode_atomic is to changed to err_code.

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

[RFC] changes for libdrm pushed for review @
https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/450

    To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    To: suraj.kandpal@intel.com>
    To: Maxime Ripard <mripard@kernel.org>
    To: Thomas Zimmermann <tzimmermann@suse.de>
    To: David Airlie <airlied@gmail.com>
    To: Simona Vetter <simona@ffwll.ch>
    To: Jani Nikula <jani.nikula@linux.intel.com>
    To: Rodrigo Vivi <rodrigo.vivi@intel.com>
    To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    To: Tvrtko Ursulin <tursulin@ursulin.net>
    To: xaver.hugl@kde.org
    To: harry.wentland@amd.com
    To: uma.shankar@intel.com
    To: louis.chauvet@bootlin.com
    To: naveen1.kumar@intel.com
    To: ramya.krishna.yella@intel.com
    Cc: dri-devel@lists.freedesktop.org
    Cc: intel-gfx@lists.freedesktop.org
    Cc: intel-xe@lists.freedesktop.org
    Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
Changes in v9:
- EDITME: describe what is new in this series revision.
- EDITME: use bulletpoints and terse descriptions.
- Link to v8: https://lore.kernel.org/r/20260129-atomic-v8-0-4cb7b0faa051@intel.com

---
Arun R Murthy (7):
      drm: Define user readable error codes for atomic ioctl
      drm/atomic: Add error_code element in atomic_state
      drm/atomic: Call complete_signaling only if prepare_signaling is done
      drm/atomic: Allocate atomic_state at the beginning of atomic_ioctl
      drm/atomic: Return user readable error in atomic_ioctl
      drm/i915/display: Error codes for async flip failures
      drm: Introduce DRM_CAP_ATOMIC_ERROR_REPORTING

 drivers/gpu/drm/drm_atomic.c                 | 31 ++++++++++
 drivers/gpu/drm/drm_atomic_uapi.c            | 89 ++++++++++++++++++++--------
 drivers/gpu/drm/drm_ioctl.c                  |  3 +
 drivers/gpu/drm/i915/display/intel_display.c | 25 ++++----
 include/drm/drm_atomic.h                     | 10 ++++
 include/uapi/drm/drm.h                       |  7 +++
 include/uapi/drm/drm_mode.h                  | 37 ++++++++++++
 7 files changed, 165 insertions(+), 37 deletions(-)
---
base-commit: cec43d5c2696af219fc2ef71dd7e93db48c80f66
change-id: 20250728-atomic-c9713fd357e4

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

[PATCH v10 1/7] 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 retry. 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, thereby creation of new
uapi/interface for returning the error code is not required.
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 as a string can also be added
on need basis by the variable failure_string in the same struct
drm_mode_atomic_err_code.

v3: Remove fixed error (Jani/Xaver)
v5: Fix kernel-doc (Jani)
v7: Rephrase the kernel doc description (Suraj)
v8: Removed the below enum and suggest to use INVALID_API_USAGE (Xaver)
	DRM_MODE_ATOMIC_ASYNC_NOT_SUPP_PLANE
	DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPP

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

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 3693d82b5279f1cf14fc2adb538ea830591cc598..71e91d4f05ee8d556e8e7137a6cdcc7f3b261a75 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	128
 
 #define DRM_MODE_TYPE_BUILTIN	(1<<0) /* deprecated */
 #define DRM_MODE_TYPE_CLOCK_C	((1<<1) | DRM_MODE_TYPE_BUILTIN) /* deprecated */
@@ -1343,6 +1344,42 @@ struct drm_mode_destroy_dumb {
 		DRM_MODE_ATOMIC_NONBLOCK |\
 		DRM_MODE_ATOMIC_ALLOW_MODESET)
 
+/**
+ * enum drm_mode_atomic_failure_codes -  error codes for failures in atomic_ioctl
+ * @DRM_MODE_ATOMIC_INVALID_API_USAGE: invallid API usage(DRM_ATOMIC not
+ *				       enabled, invalid falg, page_flip event
+ *				       with test-only, etc)
+ * @DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET: Need full modeset on this crtc
+ * @DRM_MODE_ATOMIC_NEED_FULL_MODESET: Need full modeset on all connected crtc's
+ * @DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED: Property changed in async flip
+ */
+enum drm_mode_atomic_failure_codes {
+	DRM_MODE_ATOMIC_INVALID_API_USAGE,
+	DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET,
+	DRM_MODE_ATOMIC_NEED_FULL_MODESET,
+	DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED,
+};
+
+/**
+ * struct 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_code: error codes defined in enum drm_moide_atomic_failure_code
+ * @failure_objs_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
+ * @failure_string: user readable error message string
+ */
+struct drm_mode_atomic_err_code {
+	__u64 failure_code;
+	__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

[PATCH v10 2/7] 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.
New function added to print the error message and fill the struct
err_code with proper error message and error code.

v5: Add a function for printing the error message and filling err_code
    struct
v6: Replace drm_err with drm_dbg_atomic print
v6: Add keyword "commit failed" in dbg msg (Suraj)

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
---
 drivers/gpu/drm/drm_atomic.c | 31 +++++++++++++++++++++++++++++++
 include/drm/drm_atomic.h     | 10 ++++++++++
 2 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 04925166df989bcb30b111739aa4ed5c84f3a5ae..5fd5cc4da99cea51c06da3e5f5603d9c018d4600 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2122,6 +2122,37 @@ void drm_state_dump(struct drm_device *dev, struct drm_printer *p)
 }
 EXPORT_SYMBOL(drm_state_dump);
 
+/**
+ * drm_mode_atomic_add_error_msg - function to add error code and error string
+ *
+ * @err_code: pointer to struct drm_mode_atomic_err_code that stores the failure
+ *	      reason
+ * @failure_code: failure code in enum drm_mode_atomic_failure_codes
+ * @failure_string: failure reason string message
+ *
+ * Returns: void
+ */
+void drm_mode_atomic_add_error_msg(struct drm_mode_atomic_err_code *err_code,
+				   __u64 failure_code, const char *format, ...)
+{
+	struct drm_atomic_state *state = container_of(err_code,
+						      struct drm_atomic_state,
+						      error_code);
+	va_list varg;
+	char *failure_string;
+
+	err_code->failure_code = failure_code;
+
+	va_start(varg, format);
+	failure_string = kvasprintf(GFP_ATOMIC, format, varg);
+
+	drm_dbg_atomic(state->dev, "Commit failed: %s\n", failure_string);
+	strscpy_pad(err_code->failure_string, failure_string,
+		    sizeof(err_code->failure_string));
+	va_end(varg);
+}
+EXPORT_SYMBOL(drm_mode_atomic_add_error_msg);
+
 #ifdef CONFIG_DEBUG_FS
 static int drm_state_info(struct seq_file *m, void *data)
 {
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 0b1b32bcd2bda1b92299fd369ba7c23b1c2d3dfa..e26e68a955d33c2f7caa50b89ccb7d66c2c430d8 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -646,6 +646,13 @@ struct drm_atomic_state {
 	 * commit without blocking.
 	 */
 	struct work_struct commit_work;
+
+	/* @error_code: pointer to struct holding failure reason and string
+	 *
+	 * 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);
@@ -1373,5 +1380,8 @@ drm_atomic_get_old_bridge_state(const struct drm_atomic_state *state,
 struct drm_bridge_state *
 drm_atomic_get_new_bridge_state(const struct drm_atomic_state *state,
 				struct drm_bridge *bridge);
+__printf(3, 4)
+void drm_mode_atomic_add_error_msg(struct drm_mode_atomic_err_code *err_code,
+				   __u64 failure_code, const char *format, ...);
 
 #endif /* DRM_ATOMIC_H_ */

-- 
2.25.1

[PATCH v10 3/7] drm/atomic: Call complete_signaling only if prepare_signaling is done

[Arun R Murthy]

Upon returning valid error code on atomic_ioctl failure, changes have
been done to goto error/out in cases of error instead of returining to
accommodate returning the failure codes. As part of this change
complete_signaling() will be called as part of cleanup. Check if the
fences are initialized/prepared before completing.

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
---
 drivers/gpu/drm/drm_atomic_uapi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 87de41fb445931ff8383b45839fca63123026f8e..ac84b9a9c25844985816b9c0843c44e6e763d048 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1569,7 +1569,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	struct drm_modeset_acquire_ctx ctx;
 	struct drm_out_fence_state *fence_state;
 	int ret = 0;
-	unsigned int i, j, num_fences;
+	unsigned int i, j, num_fences = 0;
 	bool async_flip = false;
 
 	/* disallow for drivers not supporting atomic: */
@@ -1719,7 +1719,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	}
 
 out:
-	complete_signaling(dev, state, fence_state, num_fences, !ret);
+	if (num_fences)
+		complete_signaling(dev, state, fence_state, num_fences, !ret);
 
 	if (ret == -EDEADLK) {
 		drm_atomic_state_clear(state);

-- 
2.25.1

[PATCH v10 4/7] drm/atomic: Allocate atomic_state at the beginning of atomic_ioctl

[Arun R Murthy]

Move atomic_state allocation to the beginning of the atomic_ioctl
to accommodate drm_mode_atomic_err_code usage for returning error
code on failures.
As atomic state is required for drm_mode_atomic_err_code to store the
error codes.

v7: Reframe commit message (Suraj)
v8: Moved the clearing fence change to a different patch (Suraj/Louis)
v9: Free allocated atomic_state before return on error, move this change
from patch 5 (Suraj)
v10: Re-order, exchange 3 and 4th patch to ensure cleanup is done in
order (Suraj)

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
---
 drivers/gpu/drm/drm_atomic_uapi.c | 30 ++++++++++++++++++------------
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index ac84b9a9c25844985816b9c0843c44e6e763d048..f295a397c26c24c6414a25bacff051bd694260c5 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1576,6 +1576,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
 		return -EOPNOTSUPP;
 
+	state = drm_atomic_state_alloc(dev);
+	if (!state)
+		return -ENOMEM;
+
+	drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
+	state->acquire_ctx = &ctx;
+	state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
+
 	/* 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)
@@ -1583,24 +1591,28 @@ 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;
+		ret = -EINVAL;
+		goto out;
 	}
 
 	if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS) {
 		drm_dbg_atomic(dev, "commit failed: invalid flag\n");
-		return -EINVAL;
+		ret = -EINVAL;
+		goto out;
 	}
 
 	if (arg->reserved) {
 		drm_dbg_atomic(dev, "commit failed: reserved field set\n");
-		return -EINVAL;
+		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;
+			ret = -EINVAL;
+			goto out;
 		}
 
 		async_flip = true;
@@ -1611,16 +1623,10 @@ 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;
+		ret = -EINVAL;
+		goto out;
 	}
 
-	state = drm_atomic_state_alloc(dev);
-	if (!state)
-		return -ENOMEM;
-
-	drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
-	state->acquire_ctx = &ctx;
-	state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
 	state->plane_color_pipeline = file_priv->plane_color_pipeline;
 
 retry:

-- 
2.25.1

[PATCH v10 5/7] 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.

v8: Replaced DRM_MODE_ATOMIC_ASYNC_NOT_SUPP_PLANE,
    DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPP with INVALID_API_USAGE
    (Xaver)
v9: Move free atomic_state on error to patch 3 (Suraj)
v10: on copy_to_user error free atomic_state and drop acquired locks
(Suraj)

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
---
 drivers/gpu/drm/drm_atomic_uapi.c | 58 +++++++++++++++++++++++++++++----------
 1 file changed, 44 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index f295a397c26c24c6414a25bacff051bd694260c5..0a4a8e8033d21a78efaeda0dca3e018dc3ae542a 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1196,6 +1196,11 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
 			ret = drm_atomic_connector_get_property(connector, connector_state,
 								prop, &old_val);
 			ret = drm_atomic_check_prop_changes(ret, old_val, prop_value, prop);
+			if (ret) {
+				drm_mode_atomic_add_error_msg(&state->error_code,
+							      DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED,
+							      "property change not allowed in async flip");
+			}
 			break;
 		}
 
@@ -1218,6 +1223,11 @@ 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) {
+				drm_mode_atomic_add_error_msg(&state->error_code,
+							      DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED,
+							      "property change not allowed in async flip");
+			}
 			break;
 		}
 
@@ -1256,9 +1266,10 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
 					ret = plane_funcs->atomic_async_check(plane, state, true);
 
 				if (ret) {
-					drm_dbg_atomic(prop->dev,
-						       "[PLANE:%d:%s] does not support async flips\n",
-						       obj->id, plane->name);
+					drm_mode_atomic_add_error_msg(&state->error_code,
+								      DRM_MODE_ATOMIC_INVALID_API_USAGE,
+								      "[PLANE:%d:%s] does not support async flip",
+								      obj->id, plane->name);
 					break;
 				}
 			}
@@ -1568,6 +1579,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	struct drm_atomic_state *state;
 	struct drm_modeset_acquire_ctx ctx;
 	struct drm_out_fence_state *fence_state;
+	struct drm_mode_atomic_err_code __user *error_code_ptr;
 	int ret = 0;
 	unsigned int i, j, num_fences = 0;
 	bool async_flip = false;
@@ -1576,6 +1588,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
 		return -EOPNOTSUPP;
 
+	if (!arg->reserved)
+		drm_dbg_atomic(dev,
+			       "memory not allocated for drm_atomic error reporting\n");
+	else
+		/* Update the error code if any error to allow user handling it */
+		error_code_ptr = (struct drm_mode_atomic_err_code __user *)
+				 (unsigned long)arg->reserved;
+
 	state = drm_atomic_state_alloc(dev);
 	if (!state)
 		return -ENOMEM;
@@ -1584,11 +1604,16 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	state->acquire_ctx = &ctx;
 	state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
 
+	memset(&state->error_code, 0, sizeof(*error_code_ptr));
+
 	/* 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)
 	 */
 	if (!file_priv->atomic) {
+		drm_mode_atomic_add_error_msg(&state->error_code,
+					      DRM_MODE_ATOMIC_INVALID_API_USAGE,
+					      "drm atomic capability not enabled");
 		drm_dbg_atomic(dev,
 			       "commit failed: atomic cap not enabled\n");
 		ret = -EINVAL;
@@ -1596,21 +1621,18 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	}
 
 	if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS) {
-		drm_dbg_atomic(dev, "commit failed: invalid flag\n");
-		ret = -EINVAL;
-		goto out;
-	}
-
-	if (arg->reserved) {
-		drm_dbg_atomic(dev, "commit failed: reserved field set\n");
+		drm_mode_atomic_add_error_msg(&state->error_code,
+					      DRM_MODE_ATOMIC_INVALID_API_USAGE,
+					      "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");
+			drm_mode_atomic_add_error_msg(&state->error_code,
+						      DRM_MODE_ATOMIC_INVALID_API_USAGE,
+						      "DRM_MODE_PAGE_FLIP_ASYNC not supported with ATOMIC ioctl");
 			ret = -EINVAL;
 			goto out;
 		}
@@ -1621,8 +1643,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	/* can't test and expect an event at the same time. */
 	if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
 			(arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) {
-		drm_dbg_atomic(dev,
-			       "commit failed: page-flip event requested with test-only commit\n");
+		drm_mode_atomic_add_error_msg(&state->error_code,
+					      DRM_MODE_ATOMIC_INVALID_API_USAGE,
+					      "page-flip event requested with test-only commit");
 		ret = -EINVAL;
 		goto out;
 	}
@@ -1725,6 +1748,13 @@ 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) {
+		if (copy_to_user(error_code_ptr, &state->error_code,
+				 sizeof(state->error_code)))
+			ret = -EFAULT;
+	}
+
 	if (num_fences)
 		complete_signaling(dev, state, fence_state, num_fences, !ret);
 

-- 
2.25.1

[PATCH v10 6/7] 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.

v8: Replaced DRM_MODE_ATOMIC_ASYNC_NOT_SUPP_PLANE,
    DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPP with INVALUD_API_USAGE
    (Xaver)

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
---
 drivers/gpu/drm/i915/display/intel_display.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 33821cc2948b6ea1f96a8adceb459a08c255d9e3..b648dbe1f0b3c70eef093f32e3e35d9187961d94 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6055,9 +6055,10 @@ static int intel_async_flip_check_uapi(struct intel_atomic_state *state,
 	}
 
 	if (intel_crtc_needs_modeset(new_crtc_state)) {
-		drm_dbg_kms(display->drm,
-			    "[CRTC:%d:%s] modeset required\n",
-			    crtc->base.base.id, crtc->base.name);
+		drm_mode_atomic_add_error_msg(&state->base.error_code,
+					      DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET,
+					      "[CRTC:%d:%s] requires full modeset",
+					      crtc->base.base.id, crtc->base.name);
 		return -EINVAL;
 	}
 
@@ -6124,9 +6125,10 @@ static int intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
 	}
 
 	if (intel_crtc_needs_modeset(new_crtc_state)) {
-		drm_dbg_kms(display->drm,
-			    "[CRTC:%d:%s] modeset required\n",
-			    crtc->base.base.id, crtc->base.name);
+		drm_mode_atomic_add_error_msg(&state->base.error_code,
+					      DRM_MODE_ATOMIC_CRTC_NEED_FULL_MODESET,
+					      "[CRTC:%d:%s] requires full modeset",
+					      crtc->base.base.id, crtc->base.name);
 		return -EINVAL;
 	}
 
@@ -6164,11 +6166,12 @@ static int intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
 
 		if (!intel_plane_can_async_flip(plane, new_plane_state->hw.fb->format,
 						new_plane_state->hw.fb->modifier)) {
-			drm_dbg_kms(display->drm,
-				    "[PLANE:%d:%s] pixel format %p4cc / modifier 0x%llx does not support async flip\n",
-				    plane->base.base.id, plane->base.name,
-				    &new_plane_state->hw.fb->format->format,
-				    new_plane_state->hw.fb->modifier);
+			drm_mode_atomic_add_error_msg(&state->base.error_code,
+						      DRM_MODE_ATOMIC_INVALID_API_USAGE,
+						      "[PLANE:%d:%s] pixel format %p4cc / 0x%llx modifier does not support async flip",
+						      plane->base.base.id, plane->base.name,
+						      &new_plane_state->hw.fb->format->format,
+						      new_plane_state->hw.fb->modifier);
 			return -EINVAL;
 		}
 

-- 
2.25.1

[PATCH v10 7/7] drm: Introduce DRM_CAP_ATOMIC_ERROR_REPORTING

[Arun R Murthy]

The new capability informs users that atomic_ioctl() supports
failure reporting when an error occurs.

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
---
 drivers/gpu/drm/drm_ioctl.c | 3 +++
 include/uapi/drm/drm.h      | 7 +++++++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ff193155129e7e863888d8958458978566b144f8..59f2b5b53830fd3aadc6e18cf49f0660a99e9c96 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -304,6 +304,9 @@ static int drm_getcap(struct drm_device *dev, void *data, struct drm_file *file_
 		req->value = drm_core_check_feature(dev, DRIVER_ATOMIC) &&
 			     dev->mode_config.async_page_flip;
 		break;
+	case DRM_CAP_ATOMIC_ERROR_REPORTING:
+		req->value = drm_core_check_feature(dev, DRIVER_ATOMIC) && 1;
+		break;
 	default:
 		return -EINVAL;
 	}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 27cc159c1d275c7a7fe057840ef792f30a582bb7..6082410bcabfb4aa37b85e5f03d3611e5aed4aa5 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -812,6 +812,13 @@ struct drm_gem_change_handle {
  * commits.
  */
 #define DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP	0x15
+/**
+ * DRM_CAP_ATOMIC_ERROR_REPORTING
+ *
+ * If set to 1, the driver supports reporting of failure codes on error in
+ * atomic ioctl().
+ */
+#define DRM_CAP_ATOMIC_ERROR_REPORTING	0x16
 
 /* DRM_IOCTL_GET_CAP ioctl argument type */
 struct drm_get_cap {

-- 
2.25.1

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Murthy, Arun R]

Any other comments/feedback on this?

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

On 23-02-2026 14:45, Arun R Murthy wrote:
> EDITME: Imported from f20260210-atomic-v9-5-525c88fd2402@intel.com
>          Please review before sending.
>
> 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.
>
> User will have to check for the capability
> DRM_CAP_ATOMIC_ERROR_REPORTING before using this feature so as to ensure
> that the driver supports failure reporting.
>
> TODO: driver specific error codes are to be added and will be done in
> the follow-up patches.
>
> TODO: Once the series is merged the element 'reserved' used for sending
> the failure code in struct drm_mode_atomic is to changed to err_code.
>
> The IGT related changes are pushed for review @
> https://patchwork.freedesktop.org/series/153330/
>
> [RFC] changes for libdrm pushed for review @
> https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/450
>
>      To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>      To: suraj.kandpal@intel.com>
>      To: Maxime Ripard <mripard@kernel.org>
>      To: Thomas Zimmermann <tzimmermann@suse.de>
>      To: David Airlie <airlied@gmail.com>
>      To: Simona Vetter <simona@ffwll.ch>
>      To: Jani Nikula <jani.nikula@linux.intel.com>
>      To: Rodrigo Vivi <rodrigo.vivi@intel.com>
>      To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>      To: Tvrtko Ursulin <tursulin@ursulin.net>
>      To: xaver.hugl@kde.org
>      To: harry.wentland@amd.com
>      To: uma.shankar@intel.com
>      To: louis.chauvet@bootlin.com
>      To: naveen1.kumar@intel.com
>      To: ramya.krishna.yella@intel.com
>      Cc: dri-devel@lists.freedesktop.org
>      Cc: intel-gfx@lists.freedesktop.org
>      Cc: intel-xe@lists.freedesktop.org
>      Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> Changes in v9:
> - EDITME: describe what is new in this series revision.
> - EDITME: use bulletpoints and terse descriptions.
> - Link to v8: https://lore.kernel.org/r/20260129-atomic-v8-0-4cb7b0faa051@intel.com
>
> ---
> Arun R Murthy (7):
>        drm: Define user readable error codes for atomic ioctl
>        drm/atomic: Add error_code element in atomic_state
>        drm/atomic: Call complete_signaling only if prepare_signaling is done
>        drm/atomic: Allocate atomic_state at the beginning of atomic_ioctl
>        drm/atomic: Return user readable error in atomic_ioctl
>        drm/i915/display: Error codes for async flip failures
>        drm: Introduce DRM_CAP_ATOMIC_ERROR_REPORTING
>
>   drivers/gpu/drm/drm_atomic.c                 | 31 ++++++++++
>   drivers/gpu/drm/drm_atomic_uapi.c            | 89 ++++++++++++++++++++--------
>   drivers/gpu/drm/drm_ioctl.c                  |  3 +
>   drivers/gpu/drm/i915/display/intel_display.c | 25 ++++----
>   include/drm/drm_atomic.h                     | 10 ++++
>   include/uapi/drm/drm.h                       |  7 +++
>   include/uapi/drm/drm_mode.h                  | 37 ++++++++++++
>   7 files changed, 165 insertions(+), 37 deletions(-)
> ---
> base-commit: cec43d5c2696af219fc2ef71dd7e93db48c80f66
> change-id: 20250728-atomic-c9713fd357e4
>
> Best regards,

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

[Patchwork]

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

== Series Details ==

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

== Summary ==

CI Bug Log - changes from CI_DRM_18020 -> Patchwork_152275v9
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_152275v9 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_152275v9, 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_152275v9/index.html

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

  Missing    (2): bat-dg2-13 fi-snb-2520m 

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

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

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live@gem_contexts:
    - bat-arls-6:         [PASS][1] -> [TIMEOUT][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18020/bat-arls-6/igt@i915_selftest@live@gem_contexts.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v9/bat-arls-6/igt@i915_selftest@live@gem_contexts.html

  
#### Warnings ####

  * igt@i915_selftest@live:
    - bat-arls-6:         [DMESG-FAIL][3] ([i915#12061]) -> [TIMEOUT][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18020/bat-arls-6/igt@i915_selftest@live.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v9/bat-arls-6/igt@i915_selftest@live.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@i915_module_load@reload:
    - bat-arls-6:         [PASS][5] -> [DMESG-WARN][6] ([i915#15738]) +39 other tests dmesg-warn
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18020/bat-arls-6/igt@i915_module_load@reload.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v9/bat-arls-6/igt@i915_module_load@reload.html

  * igt@i915_pm_rpm@module-reload:
    - bat-rpls-4:         [PASS][7] -> [DMESG-WARN][8] ([i915#13400])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18020/bat-rpls-4/igt@i915_pm_rpm@module-reload.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v9/bat-rpls-4/igt@i915_pm_rpm@module-reload.html

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

  * igt@kms_hdmi_inject@inject-audio:
    - fi-tgl-1115g4:      [PASS][11] -> [FAIL][12] ([i915#14867])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18020/fi-tgl-1115g4/igt@kms_hdmi_inject@inject-audio.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v9/fi-tgl-1115g4/igt@kms_hdmi_inject@inject-audio.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@workarounds:
    - bat-dg2-9:          [DMESG-FAIL][13] ([i915#12061]) -> [PASS][14] +1 other test pass
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18020/bat-dg2-9/igt@i915_selftest@live@workarounds.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v9/bat-dg2-9/igt@i915_selftest@live@workarounds.html
    - bat-mtlp-9:         [DMESG-FAIL][15] ([i915#12061]) -> [PASS][16] +1 other test pass
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18020/bat-mtlp-9/igt@i915_selftest@live@workarounds.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v9/bat-mtlp-9/igt@i915_selftest@live@workarounds.html

  
#### Warnings ####

  * igt@i915_selftest@live@workarounds:
    - bat-arls-6:         [DMESG-FAIL][17] ([i915#12061]) -> [DMESG-WARN][18] ([i915#15738])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18020/bat-arls-6/igt@i915_selftest@live@workarounds.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_152275v9/bat-arls-6/igt@i915_selftest@live@workarounds.html

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


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

  * Linux: CI_DRM_18020 -> Patchwork_152275v9

  CI-20190529: 20190529
  CI_DRM_18020: 4e1956bfdd4937741e5779a3d5743efec6acf57f @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_8765: 8765
  Patchwork_152275v9: 4e1956bfdd4937741e5779a3d5743efec6acf57f @ git://anongit.freedesktop.org/gfx-ci/linux

== Logs ==

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

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

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Ville Syrjälä]

On Mon, Feb 23, 2026 at 03:37:39PM +0530, Murthy, Arun R wrote:
> Any other comments/feedback on this?

Having random strings as uabi seems like a bad idea.
How would you make sure those are never changed?

> 
> Thanks and Regards,
> Arun R Murthy
> -------------------
> 
> On 23-02-2026 14:45, Arun R Murthy wrote:
> > EDITME: Imported from f20260210-atomic-v9-5-525c88fd2402@intel.com
> >          Please review before sending.
> >
> > 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.
> >
> > User will have to check for the capability
> > DRM_CAP_ATOMIC_ERROR_REPORTING before using this feature so as to ensure
> > that the driver supports failure reporting.
> >
> > TODO: driver specific error codes are to be added and will be done in
> > the follow-up patches.
> >
> > TODO: Once the series is merged the element 'reserved' used for sending
> > the failure code in struct drm_mode_atomic is to changed to err_code.
> >
> > The IGT related changes are pushed for review @
> > https://patchwork.freedesktop.org/series/153330/
> >
> > [RFC] changes for libdrm pushed for review @
> > https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/450
> >
> >      To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >      To: suraj.kandpal@intel.com>
> >      To: Maxime Ripard <mripard@kernel.org>
> >      To: Thomas Zimmermann <tzimmermann@suse.de>
> >      To: David Airlie <airlied@gmail.com>
> >      To: Simona Vetter <simona@ffwll.ch>
> >      To: Jani Nikula <jani.nikula@linux.intel.com>
> >      To: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >      To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> >      To: Tvrtko Ursulin <tursulin@ursulin.net>
> >      To: xaver.hugl@kde.org
> >      To: harry.wentland@amd.com
> >      To: uma.shankar@intel.com
> >      To: louis.chauvet@bootlin.com
> >      To: naveen1.kumar@intel.com
> >      To: ramya.krishna.yella@intel.com
> >      Cc: dri-devel@lists.freedesktop.org
> >      Cc: intel-gfx@lists.freedesktop.org
> >      Cc: intel-xe@lists.freedesktop.org
> >      Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> >
> > Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> > ---
> > Changes in v9:
> > - EDITME: describe what is new in this series revision.
> > - EDITME: use bulletpoints and terse descriptions.
> > - Link to v8: https://lore.kernel.org/r/20260129-atomic-v8-0-4cb7b0faa051@intel.com
> >
> > ---
> > Arun R Murthy (7):
> >        drm: Define user readable error codes for atomic ioctl
> >        drm/atomic: Add error_code element in atomic_state
> >        drm/atomic: Call complete_signaling only if prepare_signaling is done
> >        drm/atomic: Allocate atomic_state at the beginning of atomic_ioctl
> >        drm/atomic: Return user readable error in atomic_ioctl
> >        drm/i915/display: Error codes for async flip failures
> >        drm: Introduce DRM_CAP_ATOMIC_ERROR_REPORTING
> >
> >   drivers/gpu/drm/drm_atomic.c                 | 31 ++++++++++
> >   drivers/gpu/drm/drm_atomic_uapi.c            | 89 ++++++++++++++++++++--------
> >   drivers/gpu/drm/drm_ioctl.c                  |  3 +
> >   drivers/gpu/drm/i915/display/intel_display.c | 25 ++++----
> >   include/drm/drm_atomic.h                     | 10 ++++
> >   include/uapi/drm/drm.h                       |  7 +++
> >   include/uapi/drm/drm_mode.h                  | 37 ++++++++++++
> >   7 files changed, 165 insertions(+), 37 deletions(-)
> > ---
> > base-commit: cec43d5c2696af219fc2ef71dd7e93db48c80f66
> > change-id: 20250728-atomic-c9713fd357e4
> >
> > Best regards,

-- 
Ville Syrjälä
Intel

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Murthy, Arun R]

On 24-02-2026 12:37, Ville Syrjälä wrote:
> On Mon, Feb 23, 2026 at 03:37:39PM +0530, Murthy, Arun R wrote:
>> Any other comments/feedback on this?
> Having random strings as uabi seems like a bad idea.
> How would you make sure those are never changed?
The requirement was to have a string for logging/debugging in the UMD 
logs and KMD/display to pass the verbose information.

Discussions around this.[1][2]

[1] https://hackmd.io/f3bDn3kyRUalLn4LbMfCVQ#Commit-Failure-Feedback

[2] https://patchwork.freedesktop.org/patch/666193/?series=152276&rev=1

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

>> Thanks and Regards,
>> Arun R Murthy
>> -------------------
>>
>> On 23-02-2026 14:45, Arun R Murthy wrote:
>>> EDITME: Imported from f20260210-atomic-v9-5-525c88fd2402@intel.com
>>>           Please review before sending.
>>>
>>> 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.
>>>
>>> User will have to check for the capability
>>> DRM_CAP_ATOMIC_ERROR_REPORTING before using this feature so as to ensure
>>> that the driver supports failure reporting.
>>>
>>> TODO: driver specific error codes are to be added and will be done in
>>> the follow-up patches.
>>>
>>> TODO: Once the series is merged the element 'reserved' used for sending
>>> the failure code in struct drm_mode_atomic is to changed to err_code.
>>>
>>> The IGT related changes are pushed for review @
>>> https://patchwork.freedesktop.org/series/153330/
>>>
>>> [RFC] changes for libdrm pushed for review @
>>> https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/450
>>>
>>>       To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>       To: suraj.kandpal@intel.com>
>>>       To: Maxime Ripard <mripard@kernel.org>
>>>       To: Thomas Zimmermann <tzimmermann@suse.de>
>>>       To: David Airlie <airlied@gmail.com>
>>>       To: Simona Vetter <simona@ffwll.ch>
>>>       To: Jani Nikula <jani.nikula@linux.intel.com>
>>>       To: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>       To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>>       To: Tvrtko Ursulin <tursulin@ursulin.net>
>>>       To: xaver.hugl@kde.org
>>>       To: harry.wentland@amd.com
>>>       To: uma.shankar@intel.com
>>>       To: louis.chauvet@bootlin.com
>>>       To: naveen1.kumar@intel.com
>>>       To: ramya.krishna.yella@intel.com
>>>       Cc: dri-devel@lists.freedesktop.org
>>>       Cc: intel-gfx@lists.freedesktop.org
>>>       Cc: intel-xe@lists.freedesktop.org
>>>       Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>>>
>>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>>> ---
>>> Changes in v9:
>>> - EDITME: describe what is new in this series revision.
>>> - EDITME: use bulletpoints and terse descriptions.
>>> - Link to v8: https://lore.kernel.org/r/20260129-atomic-v8-0-4cb7b0faa051@intel.com
>>>
>>> ---
>>> Arun R Murthy (7):
>>>         drm: Define user readable error codes for atomic ioctl
>>>         drm/atomic: Add error_code element in atomic_state
>>>         drm/atomic: Call complete_signaling only if prepare_signaling is done
>>>         drm/atomic: Allocate atomic_state at the beginning of atomic_ioctl
>>>         drm/atomic: Return user readable error in atomic_ioctl
>>>         drm/i915/display: Error codes for async flip failures
>>>         drm: Introduce DRM_CAP_ATOMIC_ERROR_REPORTING
>>>
>>>    drivers/gpu/drm/drm_atomic.c                 | 31 ++++++++++
>>>    drivers/gpu/drm/drm_atomic_uapi.c            | 89 ++++++++++++++++++++--------
>>>    drivers/gpu/drm/drm_ioctl.c                  |  3 +
>>>    drivers/gpu/drm/i915/display/intel_display.c | 25 ++++----
>>>    include/drm/drm_atomic.h                     | 10 ++++
>>>    include/uapi/drm/drm.h                       |  7 +++
>>>    include/uapi/drm/drm_mode.h                  | 37 ++++++++++++
>>>    7 files changed, 165 insertions(+), 37 deletions(-)
>>> ---
>>> base-commit: cec43d5c2696af219fc2ef71dd7e93db48c80f66
>>> change-id: 20250728-atomic-c9713fd357e4
>>>
>>> Best regards,

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Ville Syrjälä]

On Tue, Feb 24, 2026 at 12:46:10PM +0530, Murthy, Arun R wrote:
> On 24-02-2026 12:37, Ville Syrjälä wrote:
> > On Mon, Feb 23, 2026 at 03:37:39PM +0530, Murthy, Arun R wrote:
> >> Any other comments/feedback on this?
> > Having random strings as uabi seems like a bad idea.
> > How would you make sure those are never changed?
> The requirement was to have a string for logging/debugging in the UMD 
> logs and KMD/display to pass the verbose information.
> 
> Discussions around this.[1][2]
> 
> [1] https://hackmd.io/f3bDn3kyRUalLn4LbMfCVQ#Commit-Failure-Feedback
> 
> [2] https://patchwork.freedesktop.org/patch/666193/?series=152276&rev=1

So the enum+obj_id thing there is perhaps the only thing that makes
sense for compositors.

Although I kinda doubt its actual usefulness to drive useful
fallback logic because often the restrictions might be a combination
of many things, and the kernel can only realistically report one of
those things.

Anyways, someone really needs to do the actual compositor
implementation so that we could see how any of this would
even work in practice.

> Thanks and Regards,
> Arun R Murthy
> -------------------
> 
> >> Thanks and Regards,
> >> Arun R Murthy
> >> -------------------
> >>
> >> On 23-02-2026 14:45, Arun R Murthy wrote:
> >>> EDITME: Imported from f20260210-atomic-v9-5-525c88fd2402@intel.com
> >>>           Please review before sending.
> >>>
> >>> 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.
> >>>
> >>> User will have to check for the capability
> >>> DRM_CAP_ATOMIC_ERROR_REPORTING before using this feature so as to ensure
> >>> that the driver supports failure reporting.
> >>>
> >>> TODO: driver specific error codes are to be added and will be done in
> >>> the follow-up patches.
> >>>
> >>> TODO: Once the series is merged the element 'reserved' used for sending
> >>> the failure code in struct drm_mode_atomic is to changed to err_code.
> >>>
> >>> The IGT related changes are pushed for review @
> >>> https://patchwork.freedesktop.org/series/153330/
> >>>
> >>> [RFC] changes for libdrm pushed for review @
> >>> https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/450
> >>>
> >>>       To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>       To: suraj.kandpal@intel.com>
> >>>       To: Maxime Ripard <mripard@kernel.org>
> >>>       To: Thomas Zimmermann <tzimmermann@suse.de>
> >>>       To: David Airlie <airlied@gmail.com>
> >>>       To: Simona Vetter <simona@ffwll.ch>
> >>>       To: Jani Nikula <jani.nikula@linux.intel.com>
> >>>       To: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >>>       To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> >>>       To: Tvrtko Ursulin <tursulin@ursulin.net>
> >>>       To: xaver.hugl@kde.org
> >>>       To: harry.wentland@amd.com
> >>>       To: uma.shankar@intel.com
> >>>       To: louis.chauvet@bootlin.com
> >>>       To: naveen1.kumar@intel.com
> >>>       To: ramya.krishna.yella@intel.com
> >>>       Cc: dri-devel@lists.freedesktop.org 
> >>>       Cc: intel-gfx@lists.freedesktop.org
> >>>       Cc: intel-xe@lists.freedesktop.org
> >>>       Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> >>>
> >>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> >>> ---
> >>> Changes in v9:
> >>> - EDITME: describe what is new in this series revision.
> >>> - EDITME: use bulletpoints and terse descriptions.
> >>> - Link to v8: https://lore.kernel.org/r/20260129-atomic-v8-0-4cb7b0faa051@intel.com
> >>>
> >>> ---
> >>> Arun R Murthy (7):
> >>>         drm: Define user readable error codes for atomic ioctl
> >>>         drm/atomic: Add error_code element in atomic_state
> >>>         drm/atomic: Call complete_signaling only if prepare_signaling is done
> >>>         drm/atomic: Allocate atomic_state at the beginning of atomic_ioctl
> >>>         drm/atomic: Return user readable error in atomic_ioctl
> >>>         drm/i915/display: Error codes for async flip failures
> >>>         drm: Introduce DRM_CAP_ATOMIC_ERROR_REPORTING
> >>>
> >>>    drivers/gpu/drm/drm_atomic.c                 | 31 ++++++++++
> >>>    drivers/gpu/drm/drm_atomic_uapi.c            | 89 ++++++++++++++++++++--------
> >>>    drivers/gpu/drm/drm_ioctl.c                  |  3 +
> >>>    drivers/gpu/drm/i915/display/intel_display.c | 25 ++++----
> >>>    include/drm/drm_atomic.h                     | 10 ++++
> >>>    include/uapi/drm/drm.h                       |  7 +++
> >>>    include/uapi/drm/drm_mode.h                  | 37 ++++++++++++
> >>>    7 files changed, 165 insertions(+), 37 deletions(-)
> >>> ---
> >>> base-commit: cec43d5c2696af219fc2ef71dd7e93db48c80f66
> >>> change-id: 20250728-atomic-c9713fd357e4
> >>>
> >>> Best regards,

-- 
Ville Syrjälä
Intel

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Murthy, Arun R]

On 24-02-2026 14:16, Ville Syrjälä wrote:
> On Tue, Feb 24, 2026 at 12:46:10PM +0530, Murthy, Arun R wrote:
>> On 24-02-2026 12:37, Ville Syrjälä wrote:
>>> On Mon, Feb 23, 2026 at 03:37:39PM +0530, Murthy, Arun R wrote:
>>>> Any other comments/feedback on this?
>>> Having random strings as uabi seems like a bad idea.
>>> How would you make sure those are never changed?
>> The requirement was to have a string for logging/debugging in the UMD
>> logs and KMD/display to pass the verbose information.
>>
>> Discussions around this.[1][2]
>>
>> [1] https://hackmd.io/f3bDn3kyRUalLn4LbMfCVQ#Commit-Failure-Feedback
>>
>> [2] https://patchwork.freedesktop.org/patch/666193/?series=152276&rev=1
> So the enum+obj_id thing there is perhaps the only thing that makes
> sense for compositors.
>
> Although I kinda doubt its actual usefulness to drive useful
> fallback logic because often the restrictions might be a combination
> of many things, and the kernel can only realistically report one of
> those things.
>
> Anyways, someone really needs to do the actual compositor
> implementation so that we could see how any of this would
> even work in practice.
Xaver is working on the compositor implementation for KWin and has 
commented[3] that the API looks good.


[3] https://patchwork.freedesktop.org/patch/696982/?series=152275&rev=6
Thanks and Regards,
Arun R Murthy
-------------------

>> Thanks and Regards,
>> Arun R Murthy
>> -------------------
>>
>>>> Thanks and Regards,
>>>> Arun R Murthy
>>>> -------------------
>>>>
>>>> On 23-02-2026 14:45, Arun R Murthy wrote:
>>>>> EDITME: Imported from f20260210-atomic-v9-5-525c88fd2402@intel.com
>>>>>            Please review before sending.
>>>>>
>>>>> 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.
>>>>>
>>>>> User will have to check for the capability
>>>>> DRM_CAP_ATOMIC_ERROR_REPORTING before using this feature so as to ensure
>>>>> that the driver supports failure reporting.
>>>>>
>>>>> TODO: driver specific error codes are to be added and will be done in
>>>>> the follow-up patches.
>>>>>
>>>>> TODO: Once the series is merged the element 'reserved' used for sending
>>>>> the failure code in struct drm_mode_atomic is to changed to err_code.
>>>>>
>>>>> The IGT related changes are pushed for review @
>>>>> https://patchwork.freedesktop.org/series/153330/
>>>>>
>>>>> [RFC] changes for libdrm pushed for review @
>>>>> https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/450
>>>>>
>>>>>        To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>>        To: suraj.kandpal@intel.com>
>>>>>        To: Maxime Ripard <mripard@kernel.org>
>>>>>        To: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>        To: David Airlie <airlied@gmail.com>
>>>>>        To: Simona Vetter <simona@ffwll.ch>
>>>>>        To: Jani Nikula <jani.nikula@linux.intel.com>
>>>>>        To: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>>>        To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>>>>        To: Tvrtko Ursulin <tursulin@ursulin.net>
>>>>>        To: xaver.hugl@kde.org
>>>>>        To: harry.wentland@amd.com
>>>>>        To: uma.shankar@intel.com
>>>>>        To: louis.chauvet@bootlin.com
>>>>>        To: naveen1.kumar@intel.com
>>>>>        To: ramya.krishna.yella@intel.com
>>>>>        Cc: dri-devel@lists.freedesktop.org
>>>>>        Cc: intel-gfx@lists.freedesktop.org
>>>>>        Cc: intel-xe@lists.freedesktop.org
>>>>>        Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>>>>>
>>>>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>>>>> ---
>>>>> Changes in v9:
>>>>> - EDITME: describe what is new in this series revision.
>>>>> - EDITME: use bulletpoints and terse descriptions.
>>>>> - Link to v8: https://lore.kernel.org/r/20260129-atomic-v8-0-4cb7b0faa051@intel.com
>>>>>
>>>>> ---
>>>>> Arun R Murthy (7):
>>>>>          drm: Define user readable error codes for atomic ioctl
>>>>>          drm/atomic: Add error_code element in atomic_state
>>>>>          drm/atomic: Call complete_signaling only if prepare_signaling is done
>>>>>          drm/atomic: Allocate atomic_state at the beginning of atomic_ioctl
>>>>>          drm/atomic: Return user readable error in atomic_ioctl
>>>>>          drm/i915/display: Error codes for async flip failures
>>>>>          drm: Introduce DRM_CAP_ATOMIC_ERROR_REPORTING
>>>>>
>>>>>     drivers/gpu/drm/drm_atomic.c                 | 31 ++++++++++
>>>>>     drivers/gpu/drm/drm_atomic_uapi.c            | 89 ++++++++++++++++++++--------
>>>>>     drivers/gpu/drm/drm_ioctl.c                  |  3 +
>>>>>     drivers/gpu/drm/i915/display/intel_display.c | 25 ++++----
>>>>>     include/drm/drm_atomic.h                     | 10 ++++
>>>>>     include/uapi/drm/drm.h                       |  7 +++
>>>>>     include/uapi/drm/drm_mode.h                  | 37 ++++++++++++
>>>>>     7 files changed, 165 insertions(+), 37 deletions(-)
>>>>> ---
>>>>> base-commit: cec43d5c2696af219fc2ef71dd7e93db48c80f66
>>>>> change-id: 20250728-atomic-c9713fd357e4
>>>>>
>>>>> Best regards,

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Ville Syrjälä]

On Tue, Feb 24, 2026 at 02:24:42PM +0530, Murthy, Arun R wrote:
> On 24-02-2026 14:16, Ville Syrjälä wrote:
> > On Tue, Feb 24, 2026 at 12:46:10PM +0530, Murthy, Arun R wrote:
> >> On 24-02-2026 12:37, Ville Syrjälä wrote:
> >>> On Mon, Feb 23, 2026 at 03:37:39PM +0530, Murthy, Arun R wrote:
> >>>> Any other comments/feedback on this?
> >>> Having random strings as uabi seems like a bad idea.
> >>> How would you make sure those are never changed?
> >> The requirement was to have a string for logging/debugging in the UMD
> >> logs and KMD/display to pass the verbose information.
> >>
> >> Discussions around this.[1][2]
> >>
> >> [1] https://hackmd.io/f3bDn3kyRUalLn4LbMfCVQ#Commit-Failure-Feedback
> >>
> >> [2] https://patchwork.freedesktop.org/patch/666193/?series=152276&rev=1
> > So the enum+obj_id thing there is perhaps the only thing that makes
> > sense for compositors.
> >
> > Although I kinda doubt its actual usefulness to drive useful
> > fallback logic because often the restrictions might be a combination
> > of many things, and the kernel can only realistically report one of
> > those things.
> >
> > Anyways, someone really needs to do the actual compositor
> > implementation so that we could see how any of this would
> > even work in practice.
> Xaver is working on the compositor implementation for KWin and has 
> commented[3] that the API looks good.
> 
> 
> [3] https://patchwork.freedesktop.org/patch/696982/?series=152275&rev=6

Until we see it I don't think there's any point in constantly
spamming this series.

> Thanks and Regards,
> Arun R Murthy
> -------------------
> 
> >> Thanks and Regards,
> >> Arun R Murthy
> >> -------------------
> >>
> >>>> Thanks and Regards,
> >>>> Arun R Murthy
> >>>> -------------------
> >>>>
> >>>> On 23-02-2026 14:45, Arun R Murthy wrote:
> >>>>> EDITME: Imported from f20260210-atomic-v9-5-525c88fd2402@intel.com
> >>>>>            Please review before sending.
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> User will have to check for the capability
> >>>>> DRM_CAP_ATOMIC_ERROR_REPORTING before using this feature so as to ensure
> >>>>> that the driver supports failure reporting.
> >>>>>
> >>>>> TODO: driver specific error codes are to be added and will be done in
> >>>>> the follow-up patches.
> >>>>>
> >>>>> TODO: Once the series is merged the element 'reserved' used for sending
> >>>>> the failure code in struct drm_mode_atomic is to changed to err_code.
> >>>>>
> >>>>> The IGT related changes are pushed for review @
> >>>>> https://patchwork.freedesktop.org/series/153330/
> >>>>>
> >>>>> [RFC] changes for libdrm pushed for review @
> >>>>> https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/450
> >>>>>
> >>>>>        To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>>>        To: suraj.kandpal@intel.com>
> >>>>>        To: Maxime Ripard <mripard@kernel.org>
> >>>>>        To: Thomas Zimmermann <tzimmermann@suse.de>
> >>>>>        To: David Airlie <airlied@gmail.com>
> >>>>>        To: Simona Vetter <simona@ffwll.ch>
> >>>>>        To: Jani Nikula <jani.nikula@linux.intel.com>
> >>>>>        To: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >>>>>        To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> >>>>>        To: Tvrtko Ursulin <tursulin@ursulin.net>
> >>>>>        To: xaver.hugl@kde.org
> >>>>>        To: harry.wentland@amd.com
> >>>>>        To: uma.shankar@intel.com
> >>>>>        To: louis.chauvet@bootlin.com
> >>>>>        To: naveen1.kumar@intel.com
> >>>>>        To: ramya.krishna.yella@intel.com
> >>>>>        Cc: dri-devel@lists.freedesktop.org
> >>>>>        Cc: intel-gfx@lists.freedesktop.org
> >>>>>        Cc: intel-xe@lists.freedesktop.org
> >>>>>        Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> >>>>>
> >>>>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> >>>>> ---
> >>>>> Changes in v9:
> >>>>> - EDITME: describe what is new in this series revision.
> >>>>> - EDITME: use bulletpoints and terse descriptions.
> >>>>> - Link to v8: https://lore.kernel.org/r/20260129-atomic-v8-0-4cb7b0faa051@intel.com
> >>>>>
> >>>>> ---
> >>>>> Arun R Murthy (7):
> >>>>>          drm: Define user readable error codes for atomic ioctl
> >>>>>          drm/atomic: Add error_code element in atomic_state
> >>>>>          drm/atomic: Call complete_signaling only if prepare_signaling is done
> >>>>>          drm/atomic: Allocate atomic_state at the beginning of atomic_ioctl
> >>>>>          drm/atomic: Return user readable error in atomic_ioctl
> >>>>>          drm/i915/display: Error codes for async flip failures
> >>>>>          drm: Introduce DRM_CAP_ATOMIC_ERROR_REPORTING
> >>>>>
> >>>>>     drivers/gpu/drm/drm_atomic.c                 | 31 ++++++++++
> >>>>>     drivers/gpu/drm/drm_atomic_uapi.c            | 89 ++++++++++++++++++++--------
> >>>>>     drivers/gpu/drm/drm_ioctl.c                  |  3 +
> >>>>>     drivers/gpu/drm/i915/display/intel_display.c | 25 ++++----
> >>>>>     include/drm/drm_atomic.h                     | 10 ++++
> >>>>>     include/uapi/drm/drm.h                       |  7 +++
> >>>>>     include/uapi/drm/drm_mode.h                  | 37 ++++++++++++
> >>>>>     7 files changed, 165 insertions(+), 37 deletions(-)
> >>>>> ---
> >>>>> base-commit: cec43d5c2696af219fc2ef71dd7e93db48c80f66
> >>>>> change-id: 20250728-atomic-c9713fd357e4
> >>>>>
> >>>>> Best regards,

-- 
Ville Syrjälä
Intel

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Jani Nikula]

On Tue, 24 Feb 2026, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> Although I kinda doubt its actual usefulness to drive useful
> fallback logic because often the restrictions might be a combination
> of many things, and the kernel can only realistically report one of
> those things.

Yeah, this is my main concern as well. The drivers will have to bail out
on the first issue they hit, whatever it is. The drivers may choose to
do the checks in different orders, resulting in different failure modes
for different drivers. And finally, accidentally making the order of the
checks part of the ABI contract is a scary prospect. Imagine user space
depending on certain checks happening first in order for the fallback
logic to work properly. Is it a kernel regression to change the order of
the checks then?

BR,
Jani.


-- 
Jani Nikula, Intel

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Murthy, Arun R]

On 24-02-2026 14:58, Jani Nikula wrote:
> On Tue, 24 Feb 2026, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>> Although I kinda doubt its actual usefulness to drive useful
>> fallback logic because often the restrictions might be a combination
>> of many things, and the kernel can only realistically report one of
>> those things.
> Yeah, this is my main concern as well. The drivers will have to bail out
> on the first issue they hit, whatever it is. The drivers may choose to
> do the checks in different orders, resulting in different failure modes
> for different drivers. And finally, accidentally making the order of the
> checks part of the ABI contract is a scary prospect. Imagine user space
> depending on certain checks happening first in order for the fallback
> logic to work properly. Is it a kernel regression to change the order of
> the checks then?
We are just reporting the 1st error that we see in the KMD and return 
from there.

Thanks and Regards,
Arun R Murthy
-------------------
> BR,
> Jani.
>
>

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Jani Nikula]

On Tue, 24 Feb 2026, "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> On 24-02-2026 14:58, Jani Nikula wrote:
>> On Tue, 24 Feb 2026, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>>> Although I kinda doubt its actual usefulness to drive useful
>>> fallback logic because often the restrictions might be a combination
>>> of many things, and the kernel can only realistically report one of
>>> those things.
>> Yeah, this is my main concern as well. The drivers will have to bail out
>> on the first issue they hit, whatever it is. The drivers may choose to
>> do the checks in different orders, resulting in different failure modes
>> for different drivers. And finally, accidentally making the order of the
>> checks part of the ABI contract is a scary prospect. Imagine user space
>> depending on certain checks happening first in order for the fallback
>> logic to work properly. Is it a kernel regression to change the order of
>> the checks then?
> We are just reporting the 1st error that we see in the KMD and return 
> from there.

Yes. But we can't guarantee all drivers will report the *same* first
error in the same circumstances. We can't guarantee we will maintain the
*same* first error over time, we can't make that promise without
painting ourselves in the corner wrt driver maintenance.

BR,
Jani.

-- 
Jani Nikula, Intel

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Xaver Hugl]

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

Hi,

I now have an implementation in KWin:
https://invent.kde.org/plasma/kwin/-/merge_requests/8991

One thing I noticed is still missing is the catch-all case / unspecified
error; the "invalid API usage" enum value would be quite misleading for
that.

- Xaver

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

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Xaver Hugl]

Am Di., 24. Feb. 2026 um 13:07 Uhr schrieb Jani Nikula
<jani.nikula@linux.intel.com>:
> Yes. But we can't guarantee all drivers will report the *same* first
> error in the same circumstances. We can't guarantee we will maintain the
> *same* first error over time, we can't make that promise without
> painting ourselves in the corner wrt driver maintenance.

That's ok. The point of the error code is to reduce the combinatorial
explosion of possible configurations compositors have to test in order
to get a working configuration, but they're still expected to do (if
necessary) many atomic tests in series, especially when modesets are
involved. If the first reported error changes, it should still
eventually reach a working configuration, even if it may take more or
less time than before.

- Xaver

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Murthy, Arun R]

On 18-03-2026 20:35, Xaver Hugl wrote:
> Hi,
>
> I now have an implementation in KWin:
> https://invent.kde.org/plasma/kwin/-/merge_requests/8991
>
> One thing I noticed is still missing is the catch-all case / unspecified
> error; the "invalid API usage" enum value would be quite misleading for
> that.

Have added the remaining error codes to the enum 
drm_mode_atomic_err_code, will push as part of patchset 11.
/**
  * enum drm_mode_atomic_failure_codes -  error codes for failures in 
atomic_ioctl
  * @DRM_MODE_ATOMIC_INVALID_API_USAGE: invallid API usage(DRM_ATOMIC not
  *                                     enabled, invalid falg, page_flip 
event
  *                                     with test-only, etc)
  * @DRM_MODE_ATOMIC_NEED_FULL_MODESET: Need full modeset on all 
connected crtc's
  * @DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED: Property changed in async flip
  * @DRM_MODE_ATOMIC_SCANOUT_BW: For a given resolution, refresh rate 
and the
  *                              color depth cannot be accomodated. 
Resolution is
  *                              to lower the refresh rate or color depth.
  * @DRM_MODE_ATOMIC_CONNECTOR_BW: Refers to the limitation on the link 
rate on
  *                                a given connector.
  * @DRM_MODE_ATOMIC_PIPE_BW: Limitation on the pipe, either pipe not 
available
  *                           or the pipe scaling factor limitation.
  * @DRM_MODE_ATOMIC_MEMORY_DOMAIN: Any other memory/bandwidth related 
limitation
  *                                 other then the ones specified above.
  * @DRM_MODE_ATOMIC_SPEC_VIOLOATION: Limitation of a particular feature 
on that
  *                                   hardware. To get to know the 
feature, the
  *                                   property/object causing this is 
being sent
  *                                   back to user @failure_objs_ptr in the
  *                                   struct drm_mode_atomic_err_code
  */
enum drm_mode_atomic_failure_codes {
         DRM_MODE_ATOMIC_INVALID_API_USAGE,
         DRM_MODE_ATOMIC_NEED_FULL_MODESET,
         DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED,
         DRM_MODE_ATOMIC_SCANOUT_BW,
         DRM_MODE_ATTOMIC_CONNECTOR_BW,
         DRM_MODE_ATTOMIC_PIPE_BW,
         DRM_MODE_ATOMIC_MEMORY_DOMAIN,
         DRM_MODE_ATOMIC_SPEC_VIOLOATION,
};


As far as the enum INVALID_API_USAGE is concerned, there is a certain 
understanding on the
usage of the atomic_ioctl,  any miss in that would fall in this 
category. Some of them include
     - Driver doesnt support atomic, but still atomic_ioctl being used
     - Invalid/Junk flags
     - Async flip not supported
     - Flag page flip event along with test only is not supported
If changing this INVALID_API_USAGE to UNSPECIFIED_ERROR makes more 
sense, I can change that.

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

> - Xaver
>

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Xaver Hugl]

> Have added the remaining error codes to the enum
> drm_mode_atomic_err_code, will push as part of patchset 11.
I think it would be best to limit the enum values to actionable
things. Connector and scanout bandwidth sound useful and pretty
straight-forward to me, but the three other new values don't seem
useful for compositors at the moment.

> DRM_MODE_ATTOMIC_PIPE_BW
Compositors aren't aware of pipes. What would they do with that information?

> DRM_MODE_ATOMIC_MEMORY_DOMAIN
> DRM_MODE_ATOMIC_SPEC_VIOLOATION
I can't think of anything a compositor would do differently with these
vs. "unspecified_error".

> As far as the enum INVALID_API_USAGE is concerned, there is a certain
> understanding on the
> usage of the atomic_ioctl,  any miss in that would fall in this
> category.
Invalid API usage would mean the compositor did something it can know
in advance is wrong based on the KMS API. It can't be used as the
default value.

> Some of them include
>      - Driver doesnt support atomic, but still atomic_ioctl being used
>      - Invalid/Junk flags
>      - Async flip not supported
>      - Flag page flip event along with test only is not supported
> If changing this INVALID_API_USAGE to UNSPECIFIED_ERROR makes more
> sense, I can change that.
No, they're two different things. We need both, and unspecified_error
needs to be the default for when the driver doesn't set anything more
specific.

- Xaver

Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure

[Murthy, Arun R]

On 24-03-2026 02:49, Xaver Hugl wrote:
>> Have added the remaining error codes to the enum
>> drm_mode_atomic_err_code, will push as part of patchset 11.
> I think it would be best to limit the enum values to actionable
> things. Connector and scanout bandwidth sound useful and pretty
> straight-forward to me, but the three other new values don't seem
> useful for compositors at the moment.
>
>> DRM_MODE_ATTOMIC_PIPE_BW
> Compositors aren't aware of pipes. What would they do with that information?

There are scenarios where two pipes driving a single connector, in that 
case compositor will be informed on the unavailability of pipe, on the 
other hand, if a given pipe scaler factor couldnt be supported due to 
b/w limitation, that would fall into this category. The object pointer 
would precisely convey the property causing this error.


>
>> DRM_MODE_ATOMIC_MEMORY_DOMAIN
>> DRM_MODE_ATOMIC_SPEC_VIOLOATION
> I can't think of anything a compositor would do differently with these
> vs. "unspecified_error".

Added this based on the feedback from 
https://hackmd.io/f3bDn3kyRUalLn4LbMfCVQ#Commit-Failure-Feedback

>> As far as the enum INVALID_API_USAGE is concerned, there is a certain
>> understanding on the
>> usage of the atomic_ioctl,  any miss in that would fall in this
>> category.
> Invalid API usage would mean the compositor did something it can know
> in advance is wrong based on the KMS API. It can't be used as the
> default value.

Understand that it cant be a default error, will add another entry 
DRM_MODE_ATOMIC_UNDEFINED_ERROR which would be the default one.


>> Some of them include
>>       - Driver doesnt support atomic, but still atomic_ioctl being used
>>       - Invalid/Junk flags
>>       - Async flip not supported
>>       - Flag page flip event along with test only is not supported
>> If changing this INVALID_API_USAGE to UNSPECIFIED_ERROR makes more
>> sense, I can change that.
> No, they're two different things. We need both, and unspecified_error
> needs to be the default for when the driver doesn't set anything more
> specific.

Got it as commented above, will add DRM_MODE_ATOMIC_UNDEFINED_ERROR 
which would be for default error.

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

> - Xaver