On Tuesday, June 16th, 2026 at 13:16, Pekka Paalanen <[email protected]> wrote:
> On Sat, 30 May 2026 17:14:44 +0000 > Simon Ser <[email protected]> wrote: > > > Currently user-space can only request page-flip events for all CRTCs > > included > > in an atomic commit. This is cumbersome with multi-CRTC commits: when > > moving a > > plane from a different CRTC, or when disabling a plane, user-space has no > > way > > to opt-out of the page-flip events. > > > > Additionally, page-flip events are invalid for already-disable planes, so > > Hi Simon, > > do you mean CRTCs? I find "already disabled" to be not really clear > that you mean off->off transition. Oh, yeah, indeed! > > user-space needs to add special cases [1]. Libraries cannot add planes to > > the > > commit without risking causing unexpected page-flip events for the > > compositor [2]. > > If a library adds a plane that is currently associated with another > CRTC, would it not be a logic error in userspace if it didn't expect > that CRTC to be involved? Mostly likely if it succeeds, the plane > would disappear from its old CRTC unintended. > > If a CRTC is unexpectedly involved, userspace risks EBUSY when it wants > to update that CRTC for real. The plane is involved anyways, and the library can figure that out. The library is fully managing the plane, and has ensured it's turned off before migrating it to a new CRTC. What's unexpected and unavoidable is the page-flip event on the old CRTC. > > Figuring out what CRTCs get implicitly included in a commit is > > non-trivial [3]. > > Yes, but is this actually helpful rather than making the failures more > rare and harder to debug? I don't believe spurious page-flip events help that much in that regard TBH. This only helps if the page-flip flag is on and user-space didn't mean to include these other CRTCs. The benefits of the new API outweigh the small cost of sometimes finding a bug a bit quicker. If some user-space believes otherwise, they can still keep using the old global flag. > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > > index 63ead8ba6756..5ad6681bd47c 100644 > > --- a/drivers/gpu/drm/drm_crtc.c > > +++ b/drivers/gpu/drm/drm_crtc.c > > @@ -248,6 +248,11 @@ struct dma_fence *drm_crtc_create_fence(struct > > drm_crtc *crtc) > > * The sharpness effect takes place post blending on the final composed > > output. > > * If the feature is disabled, the content remains same without any > > sharpening effect > > * and when this feature is applied, it enhances the clarity of the > > content. > > + * PAGE_FLIP_EVENT: > > + * Atomic property for requesting a page-flip event on this CRTC. > > + * > > + * The value of this property is an integer value which always reads as > > + * zero and can be written with 1 to request the event. > > It took me a while to realise; should probably explain here that if one > uses this, then they would not use DRM_MODE_PAGE_FLIP_EVENT at the same > time. Right. > Does this allow asking for an event for a CRTC off->off > transition? It does not.
