On Friday, August 7, 2020 11:07 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Aug 06, 2020 at 10:33:31AM +0000, Simon Ser wrote:
Some drivers may expose primary planes compatible with multiple CRTCs. Make this clear in the docs: the current wording may be misunderstood as "exactly one primary plane per CRTC".
Signed-off-by: Simon Ser contact@emersion.fr Cc: Daniel Vetter daniel@ffwll.ch
drivers/gpu/drm/drm_plane.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index b7b90b3a2e38..108a922e8c23 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -49,8 +49,8 @@
- &struct drm_plane (possibly as part of a larger structure) and registers it
- with a call to drm_universal_plane_init().
- Cursor and overlay planes are optional. All drivers should provide one
- primary plane per CRTC to avoid surprising userspace too much. See enum
- Cursor and overlay planes are optional. All drivers should provide at least
- one primary plane per CRTC to avoid surprising userspace too much. See enum
I think that's even more confusing, since this reads like there could be multiple primary planes for a specific CRTC. That's not the case, there' only one pointer going from drm_crtc->primary to a drm_plane in the kernel.
The problem is that userspace doesn't have a drm_property to read this pointer, and needs to guess.
I thought the rule is:
Nth primary plane (or cursor) is the primary plane for the Nth crtc. Enumaration with increasing drm kms object ids.
And I guess we should explain that on some hw any plane (including primary ones, since that's only a sw construct) can be freely assinged to crtc.
Eh, wow. Okay, I didn't expect that. :P
What does drm_crtc->primary mean in case a GPU exposes more than one CRTC in the primary planes' possible_crtcs bitfield? Does this pointer change if I assign primary plane 2 to CRTC 1? Is the primary n → CRTC n assignment just a default?
Maybe we can just say that at most a single primary plane may be assigned to a CRTC, and that a primary plane may be compatible with multiple CRTCs?
Yes it's probably the most gloriously bonkers uapi we've come up with. Might be so bad that a libdrm helper to look up the primary plane for a crtc (or it's cursor plane if it exists) would be in order :-)
Well, if user-space can change drm_crtc->primary, I'm not sure this is a good idea.