On Thu, 14 May 2020 at 08:25, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > On Thu, May 14, 2020 at 9:18 AM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > On Thu, 14 May 2020 at 08:08, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > I'd be very much in favour of putting the blocking down in the kernel > > at least until the kernel can give us a clear indication to tell us > > what's going on, and ideally which other resources need to be dragged > > in, in a way which is distinguishable from your compositor having > > broken synchronisation. > > We know, the patch already computes that ... So would be a matter of > exporting that to userspace. We have a mask of all additional crtc > that will get an event and will -EBUSY until that's done. Yep, but unless and until that happens, could we please get this in? Given it would require uAPI changes, we'd need to modify all the compositors to work with the old path (random EBUSY) and the new path (predictable and obvious), so at least preserving the promise that per-CRTC updates are really independent would be good. Cheers, Daniel
