On Thu, Feb 11, 2021 at 04:14:02PM +0000, Daniel Stone wrote: > On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä > <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote: > > > The WARN_ON only happens if allow_modeset == false. If allow_modeset == true, > > > then the driver is allowed to steal an unrelated pipe. > > > > > > Maybe i915 is stealing a pipe without allow_modeset? > > > > No. All page flips etc. will have to get split up internally > > between multiple crtcs. > > I think this is the salient point. > > > So I think there's basically three options: > > a) massive rewrite of i915 to bypass even more of drm_atomic stuff > > b) allow i915 to silence that warning, which opens up the question > > whether the warn is doing any good if it can just be bypassed > > c) nuke the warning entirely > > > > a) is not going to happen, and it would any way allow i915 to > > do things any which way it wants without tripping the warn, > > rendering the warn entirely toothless. > > > > Hmm. Maybe there is a d) which would be to ignore all crtcs > > that are not logically enabled in the warn? Not sure if that > > could allow something to slit through that people want it to > > catch? > > So from what I understand, if I enable CRTC 44 and the driver > magically decides to split it up as a 'big-joiner' output, it will > also steal CRTC 50 to work as the other half of the output. Then if I > attach plane 47 to CRTC 44, posting a FB to plane 47 will result in me > getting atomic completion events for both CRTC 44 and CRTC 50? > > That's not OK from a userspace perspective. If you want to do magic to > create the illusion of a single CRTC, then that magic needs to be > consistent. At the moment it's the worst kind of magic: it does > implicit things under the hood for you, but then leaks all of the > behind-the-scenes detail into userspace. > > Continuing with that would force us all to just ignore whatever events > we see, because we can't reason about what they may be or why they're > generated. Which doesn't allow for any kind of best practice in > userspace. You should only get externally visibile events for stuff in your request. Or at least if that's not the case then the atomic code is already bork regardless of bigjoiner. -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
