On Thu, 23 Jul 2026 16:02:48 +0000 Simon Ser <[email protected]> wrote:
> 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. Hi, do you mean it currently works like this: 0. The plane is active on CRTC A. 1. Submit update 1 with CRTC A, turn the plane off on CRTC A. 2. Update 1 completes, and delivers its pageflip event. 3. Submit update 2 with CRTC B, turn the plane on on CRTC B. 4. Update 2 completes and delivers pageflip events on *both* CRTC B and A? You want to prevent the pageflip event from CRTC A in step 4? Or what is the scenario you have in mind? Thanks, pq > > > 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.
pgpTNAvOLr2M1.pgp
Description: OpenPGP digital signature
