On Thu, Apr 28, 2016 at 11:52 PM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: >> > I thought turning the plane off was done by setting >> > the framebuffer to NULL (in which case the src and crtc coordinates must >> > of course be ignored) ? >> >> That's another way. However setting the fb to 0 is a bit different, as >> then you're not holding a ref on the fb (nor does it get pinned etc.). >> So eg. if you want to make sure that you really can pin the fb, but >> want to have the plane disabled for a bit, you could just the clear out >> the coordinates. >> >> Also from an implementation POV it's no different than the plane just >> getting clipped away entirely, so supporting this way of disabling a >> plane has no extra cost really. > > This really needs to be captured in a uapi documentation, this is the first > time I hear about that feature, and I'm pretty sure I'm not the only one. We > can't expect drivers to implement a consistent behaviour if the expected > behaviour isn't documented. I think we also have some room for better helpers. There's one to validate plane state, but it was written back for legacy planes and so takes slightly different arguments than what drm_plane_state provides. Doing an atomic version of that would likely get rid of lots of duplicated boilerplate all over drivers. And that helper does compute bool visible how Ville explained here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
