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@ffwll.ch wrote:
On Thu, May 14, 2020 at 9:18 AM Daniel Stone daniel@fooishbar.org wrote:
On Thu, 14 May 2020 at 08:08, Daniel Vetter daniel.vetter@ffwll.ch 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