On Thu, May 14, 2020 at 9:18 AM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > Hi, > > On Thu, 14 May 2020 at 08:08, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > > Did anything happen with this? > > > > Nope. There's an igt now that fails with this, and I'm not sure > > whether changing the igt is the right idea or not. > > > > I'm kinda now thinking about changing this to instead document under > > which exact situations you can get a spurious EBUSY, and enforcing > > that in the code with some checks. Essentially only possible if you do > > a ALLOW_MODESET | NONBLOCKING on the other crtc. And then tell > > userspace you get to eat that. We've been shipping with this for so > > long by now that's defacto the uapi anyway :-/ > > > > Thoughts? Too horrible? > > I've been trying to avoid that, to be honest. Taking a random delay > because the kernel needs to do global things is fine. But making > userspace either do an expensive/complicated cross-CRTC > synchronisation is less easy; for some compositors, that means > reaching across threads to make sure all CRTCs are quiescent. Either > that, or deferring your ALLOW_MODESET to somewhere else, like an idle > handler, far away from where you were originally trying to do it, > which wouldn't be pleasant. The other option is that we teach people > to ignore EBUSY as random noise which can just sometimes happen and to > try again (when? how often? and you still have cross-CRTC > synchronisation issues), which doesn't scream compositor best practice > to me. > > 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
