| Message ID | 20201216202222.48146-9-contact@emersion.fr (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/doc: improve plane property docs | expand |
On Wed, Dec 16, 2020 at 09:22:22PM +0100, Simon Ser wrote: > Add a new entry for "type" in the section for standard plane properties. > > Signed-off-by: Simon Ser <contact@emersion.fr> > Cc: Daniel Vetter <daniel@ffwll.ch> > Cc: Pekka Paalanen <ppaalanen@gmail.com> Looks solid, bunch of comments for extensions and more clarity below. -Daniel > --- > drivers/gpu/drm/drm_plane.c | 39 +++++++++++++++++++++++++++++++++---- > 1 file changed, 35 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > index 4c1a45ac18e6..e21e0caaca0f 100644 > --- a/drivers/gpu/drm/drm_plane.c > +++ b/drivers/gpu/drm/drm_plane.c > @@ -49,10 +49,8 @@ > * &struct drm_plane (possibly as part of a larger structure) and registers it > * with a call to drm_universal_plane_init(). > * > - * The type of a plane is exposed in the immutable "type" enumeration property, > - * which has one of the following values: "Overlay", "Primary", "Cursor" (see > - * enum drm_plane_type). A plane can be compatible with multiple CRTCs, see > - * &drm_plane.possible_crtcs. > + * Each plane has a type, see enum drm_plane_type. A plane can be compatible > + * with multiple CRTCs, see &drm_plane.possible_crtcs. > * > * Legacy uAPI doesn't expose the primary and cursor planes directly. DRM core > * relies on the driver to set the primary and optionally the cursor plane used > @@ -66,6 +64,39 @@ > * > * DRM planes have a few standardized properties: > * > + * 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. > + * 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). > + * "Cursor": > + * To enable this plane, using a framebuffer configured without scaling > + * or cropping and with the following properties is the most likely to > + * work: > + * > + * - If the driver provides the capabilities &DRM_CAP_CURSOR_WIDTH and > + * &DRM_CAP_CURSOR_HEIGHT, create the framebuffer with this size. > + * Otherwise, create a framebuffer with the size 64x64. > + * - If the driver doesn't support modifiers, create a framebuffer with > + * a linear layout. Otherwise, use the IN_FORMATS plane property. Same here, I think we should mention this is used implicitly (but only on some drivers, there atomic drivers which do _not_ expose their cursor as a cursor plane). > + * > + * Drivers may support more features for the cursor plane, user-space > + * can find out with test-only atomic commits. > + * "Overlay": > + * Neither primary nor cursor. This should mention that these are the only planes exposed when universal planes isnt set. > + * > * IN_FORMATS: > * Blob property which contains the set of buffer format and modifier > * pairs supported by this plane. The blob is a drm_format_modifier_blob > -- > 2.29.2 >
On Wednesday, December 16th, 2020 at 10:23 PM, Daniel Vetter <daniel@ffwll.ch> 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.
On Thu, Dec 17, 2020 at 11:41 AM Simon Ser <contact@emersion.fr> wrote: > > On Wednesday, December 16th, 2020 at 10:23 PM, Daniel Vetter <daniel@ffwll.ch> 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
On Thursday, December 17th, 2020 at 11:52 AM, Daniel Vetter <daniel@ffwll.ch> wrote: > > > > + * 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. Oh, right, good idea, this sounds important. Will add in v2.
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 4c1a45ac18e6..e21e0caaca0f 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -49,10 +49,8 @@ * &struct drm_plane (possibly as part of a larger structure) and registers it * with a call to drm_universal_plane_init(). * - * The type of a plane is exposed in the immutable "type" enumeration property, - * which has one of the following values: "Overlay", "Primary", "Cursor" (see - * enum drm_plane_type). A plane can be compatible with multiple CRTCs, see - * &drm_plane.possible_crtcs. + * Each plane has a type, see enum drm_plane_type. A plane can be compatible + * with multiple CRTCs, see &drm_plane.possible_crtcs. * * Legacy uAPI doesn't expose the primary and cursor planes directly. DRM core * relies on the driver to set the primary and optionally the cursor plane used @@ -66,6 +64,39 @@ * * DRM planes have a few standardized properties: * + * type: + * Immutable property describing the type of the plane. + * + * For user-space which has enabled the &DRM_CLIENT_CAP_UNIVERSAL_PLANES + * 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. + * "Cursor": + * To enable this plane, using a framebuffer configured without scaling + * or cropping and with the following properties is the most likely to + * work: + * + * - If the driver provides the capabilities &DRM_CAP_CURSOR_WIDTH and + * &DRM_CAP_CURSOR_HEIGHT, create the framebuffer with this size. + * Otherwise, create a framebuffer with the size 64x64. + * - If the driver doesn't support modifiers, create a framebuffer with + * a linear layout. Otherwise, use the IN_FORMATS plane property. + * + * Drivers may support more features for the cursor plane, user-space + * can find out with test-only atomic commits. + * "Overlay": + * Neither primary nor cursor. + * * IN_FORMATS: * Blob property which contains the set of buffer format and modifier * pairs supported by this plane. The blob is a drm_format_modifier_blob
Add a new entry for "type" in the section for standard plane properties. Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <ppaalanen@gmail.com> --- drivers/gpu/drm/drm_plane.c | 39 +++++++++++++++++++++++++++++++++---- 1 file changed, 35 insertions(+), 4 deletions(-)