On Thu, Dec 17, 2020 at 11:41 AM Simon Ser <contact@xxxxxxxxxxx> wrote:
>
> On Wednesday, December 16th, 2020 at 10:23 PM, Daniel Vetter <daniel@xxxxxxxx> wrote:
>
> > > + * type:
> > > + * Immutable property describing the type of the plane.
> > > + *
> > > + * For user-space which has enabled the &DRM_CLIENT_CAP_UNIVERSAL_PLANES
> >
> > While we're at this: Does the kerneldoc for this cap mention that it's
> > implicitly enabled when you're enabling atomic?
> >
> > Maybe worth repeating here too.
>
> Good point. v2 will do both.
>
> > > + * capability, the plane type is just a hint and is mostly superseded by
> > > + * atomic test-only commits. The type hint can still be used to come up
> > > + * more easily with a plane configuration accepted by the driver.
> > > + *
> > > + * The value of this property can be one of the following:
> > > + *
> > > + * "Primary":
> > > + * To light up a CRTC, attaching a primary plane is the most likely to
> > > + * work if it covers the whole CRTC and doesn't have scaling or
> > > + * cropping set up.
> > > + *
> > > + * Drivers may support more features for the primary plane, user-space
> > > + * can find out with test-only atomic commits.
> >
> > We need to mention here that this is the implicit plane used by the
> > PAGE_FLIP and SETCRTC ioctl (maybe spell them out in full since these are
> > userspace docs).
>
> I intentionally didn't write that down here, because as previously discussed,
> user-space has no way to guess the drm_crtc.{primary,cursor} pointers, so
> user-space cannot guess which planes will be used for legacy IOCTLs. Adding any
> hint that user-space _could_ do it will result in broken user-space.
Hm then at least a warning that userspace must not mix legacy ioctls
with using primary planes explicitly, since havoc will ensue? More
relevant for cursor planes, since some compositors do use atomic +
legacy cursor planes, but imo good to have the same blurb with the
list of relevant ioctls for each.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
