> -----Original Message----- > From: Xaver Hugl <[email protected]> > Sent: Friday, June 26, 2026 4:39 AM > To: Murthy, Arun R <[email protected]> > Cc: Maarten Lankhorst <[email protected]>; Maxime Ripard > <[email protected]>; Thomas Zimmermann <[email protected]>; David > Airlie <[email protected]>; Simona Vetter <[email protected]>; Jani Nikula > <[email protected]>; Vivi, Rodrigo <[email protected]>; Joonas > Lahtinen <[email protected]>; Tvrtko Ursulin > <[email protected]>; [email protected]; Shankar, Uma > <[email protected]>; [email protected]; Kumar, Naveen1 > <[email protected]>; Yella, Ramya Krishna > <[email protected]>; [email protected]; intel- > [email protected]; [email protected]; Kandpal, Suraj > <[email protected]> > Subject: Re: [PATCH v11 1/7] drm: Define user readable error codes for atomic > ioctl > > Hi, > Sorry for getting back late on this!
> I finally got around to updating the KWin implementation, and made it handle > some more cases. I found some issues though. > Good to hear! If the design end to end flow wise looks good, can I get an ACK on this. So that I can go ahead get the drm-core patches merged work on to enhance/complete this. > Am Di., 31. März 2026 um 11:06 Uhr schrieb Arun R Murthy > <[email protected]>: > > +/** > > + * enum drm_mode_atomic_failure_codes - error codes for failures in > > +atomic_ioctl > > + * @DRM_MODE_ATOMIC_UNSPECIFIED_ERROR: this is the > default/unspecified error. > > + * @DRM_MODE_ATOMIC_INVALID_API_USAGE: invallid API > usage(DRM_ATOMIC not > > + * enabled, invalid falg, page_flip > > event > typo: falg -> flag > > > + * 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 > typo: accomodated -> accommodated > > > + * 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. > What are actionable things a compositor can or should do in response to pipe One simple correctness would be to move on to the next available pipe. Reason for failure can be un-availability of the pipe(KMD internally maybe using it for joiner purpose), pipe scaling limitation, etc... > bandwidth limitations? Just turning off displays, using a lower resolution or > refresh rate? It's not clear to me if it's practically different to > scanout_bw in > that way. > > > + * @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 > I didn't find any case these two values would be useful in KWin yet, should we > just leave them as "unspecified" for now? > Added this based on the feedback from the open forum. This failure code is basically for a particular feature not supported by the hardware. What correctness can the compositor do depends is decided from the obj sent back from the KMD. KMD will send the object that is causing the failure and compositor can go for sw composition and retry. Few examples falling under this failure code is, async failure on cursor plane which is not supported on Intel hardware. So the object will point to the cursor plane enable, and as a corrective measurement compositor can go for sw composition of cursor plane. Another example can be a modifier/pixel format which is not supported by that plane. > > +struct drm_mode_atomic_err_code { > > + __u64 failure_code; > > + __u64 failure_objs_ptr; > I made use of the object list in the KWin implementation for the > CONNECTOR_BW case, to reduce the mode resolution and refresh rate on only > the affected connector. > When I did that though, I noticed that the memory management of that pointer > isn't defined. How is it supposed to work? > At the moment drm bails out on the first failure even though the commit can have multiple failures. So on first failure means that there will be only one obj(not a hard rule, two object can point to a single failure as well) > I think a good way to do it could be to let userspace set it to a pointer to > an > array of uint32_t + specify the max number of elements in count_objs. Either > way, if it's included in the struct, its use needs to be implemented, so these > questions are definitely answered and it can be tested. > Yes, the pointer will have to be allocated by the user and the size of this is the number for objects that is being sent in the atomic_commit. Lets say there are 5 changes that user is doing in this atomic_commit, so compositor will have to allocate 5 u32 for the failure_obj_ptr.(each pointing to the obj id) KMD on failure, will send the object causing this failure and if the failure causing object are only 2 then the count_objs will be 2. In this case compositor can get to know that only 2 objects of the 5 objects is causing the failure and can further get back the object from the object id. Thanks and Regards, Arun R Murthy -------------------- > - Xaver
