From: "Murthy, Arun R" <arun.r.murthy@intel.com>
To: "Kandpal, Suraj" <suraj.kandpal@intel.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Jani Nikula <jani.nikula@linux.intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
"xaver.hugl@kde.org" <xaver.hugl@kde.org>,
"harry.wentland@amd.com" <harry.wentland@amd.com>,
"Shankar, Uma" <uma.shankar@intel.com>,
"louis.chauvet@bootlin.com" <louis.chauvet@bootlin.com>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH v6 1/5] drm: Define user readable error codes for atomic ioctl
Date: Tue, 6 Jan 2026 09:33:37 +0530 [thread overview]
Message-ID: <6a5bb2e7-73b7-436f-bcbb-da6227b30115@intel.com> (raw)
In-Reply-To: <DM3PPF208195D8D40A2E899BB7D51A45B25E3FAA@DM3PPF208195D8D.namprd11.prod.outlook.com>
Thanks for the review!
On 29-10-2025 12:32, Kandpal, Suraj wrote:
>> Subject: [PATCH v6 1/5] drm: Define user readable error codes for atomic ioctl
>>
>> 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
> Or Any ? I think you need to rephrase
Done!
>> 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.
> This sentence seems a little weird can you correct this.
Done!
>> The element 'reserved' in the struct drm_mode_atomic is used for returning
>> the user readable error code. This points to the struct
> In that case why leave the element name as 'reserved' should that be changed
Good thought!
There are drm clients checking for this reserved variable to be NULL as
its unused.
Once this patch is merged, then will a follow-on patch to change this
variable name.
>> drm_mode_atomic_err_code. Failure reasons have been initialized in
>> DRM_MODE_ATOMIC_FAILURE_REASON.
> I don't see the code for this here.
Done! Updated!
>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>> ---
>> include/uapi/drm/drm_mode.h | 41
>> +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 41 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index
>> 1e0e02a79b5c8db200cf9fd35edfe163d701cbd5..1e9eeae472e74bbd1b5e0b6f7
>> 9f9782cafaf5b6e 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 */
>> @@ -1205,6 +1206,46 @@ struct drm_mode_destroy_dumb {
>> DRM_MODE_ATOMIC_NONBLOCK |\
>> DRM_MODE_ATOMIC_ALLOW_MODESET)
>>
>> +/**
>> + * enum drm_mode_atomic_err_code - 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
> Should this be just be CRTC_NEED_MODESET to make it differ from the below definition.
Taken care of to match the error code/function in the KMD.
>> on this
>> +crtc
>> + * @DRM_MODE_ATOMIC_NEED_FULL_MODESET: Need full modeset on all
>> +connected crtc's
>> + * @DRM_MODE_ATOMIC_ASYN_NOTSUPP_PLANE: Aync flip not supported
> Typos here
> * DRM_MODE_ATOMIC_ASYNC_NOT_SUPP_PLANE
> * Async
Done!
Thanks and Regards,
Arun R Murthy
-------------------
>
> Regards,
> Suraj Kandpal
>
>> on this
>> +plane
>> + * DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPP: Modifier not
>> supported by
>> +async flip
>> + * @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_NOT_SUPP_PLANE,
>> + DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPP,
>> + DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED,
>> +};
>> +
>> +/**
>> + * 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_string_ptr: pointer to user readable error message 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_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
next prev parent reply other threads:[~2026-01-06 4:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-09 9:32 [PATCH v6 0/5] User readable error codes on atomic_ioctl failure Arun R Murthy
2025-10-09 9:32 ` [PATCH v6 1/5] drm: Define user readable error codes for atomic ioctl Arun R Murthy
2025-10-29 7:02 ` Kandpal, Suraj
2026-01-06 4:03 ` Murthy, Arun R [this message]
2025-10-09 9:32 ` [PATCH v6 2/5] drm/atomic: Add error_code element in atomic_state Arun R Murthy
2025-10-29 7:53 ` Kandpal, Suraj
2025-10-09 9:32 ` [PATCH v6 3/5] drm/atomic: Allocate atomic_state at the beginning of atomic_ioctl Arun R Murthy
2025-10-29 7:46 ` Kandpal, Suraj
2026-01-06 4:03 ` Murthy, Arun R
2025-10-09 9:32 ` [PATCH v6 4/5] drm/atomic: Return user readable error in atomic_ioctl Arun R Murthy
2025-10-29 8:15 ` Kandpal, Suraj
2026-01-06 4:03 ` Murthy, Arun R
2025-10-09 9:32 ` [PATCH v6 5/5] drm/i915/display: Error codes for async flip failures Arun R Murthy
2025-10-09 10:19 ` ✗ CI.checkpatch: warning for User readable error codes on atomic_ioctl failure (rev5) Patchwork
2025-10-09 10:20 ` ✓ CI.KUnit: success " Patchwork
2025-10-09 10:35 ` ✗ CI.checksparse: warning " Patchwork
2025-10-09 10:57 ` ✓ Xe.CI.BAT: success " Patchwork
2025-10-09 13:46 ` ✗ Xe.CI.Full: failure " Patchwork
2025-10-28 2:59 ` [PATCH v6 0/5] User readable error codes on atomic_ioctl failure Murthy, Arun R
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a5bb2e7-73b7-436f-bcbb-da6227b30115@intel.com \
--to=arun.r.murthy@intel.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=louis.chauvet@bootlin.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=suraj.kandpal@intel.com \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.de \
--cc=uma.shankar@intel.com \
--cc=xaver.hugl@kde.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox