Hi, I finally got around to updating the KWin implementation, and made it handle some more cases. I found some issues though.
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 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? > +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? 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. - Xaver
