On Thu, May 14, 2020 at 08:40:21AM +0100, Daniel Stone wrote: > 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. I haven't found the time to look at the intel-gfx-ci fail in igt nor really think about that. Nor care enough to just hammer this ignoring ci, since I didn't even get around to understand why the igt now fails If someone else takes this over, happy to see it land. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
