If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls. Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition to universal planes will continue to operate
without any change to behavior.
Note that there's a bit of a mismatch between the legacy cursor ioctls
and the universal plane API's --- legacy ioctl's use driver buffer
handles directly whereas the universal plane API takes drm_framebuffers.
Since there's no way to recover the driver handle from a
drm_framebuffer, we can implement legacy ioctl's in terms of universal
plane interfaces, but cannot implement universal plane interfaces in
terms of legacy ioctls. Specifically, there's no way to create a
general cursor helper in the way we previously created a primary plane
helper.
It's important to land this patch before any patches that add universal
cursor support to individual drivers so that drivers don't have to worry
about juggling two different styles of reference counting for cursor
buffers when userspace mixes and matches legacy and universal cursor
calls. With this patch, a driver that switches to universal cursor
support may assume that all cursor buffers are wrapped in a
drm_framebuffer and can rely on framebuffer reference counting for all
cursor operations.
v4:
- Add comments pointing out setplane_internal's reference-eating
semantics.
v3:
- Drop drm_mode_rmfb() call that is no longer needed now that we're
using setplane_internal(), which takes care of deref'ing the
appropriate framebuffer.
v2:
- Use new add_framebuffer_internal() function to create framebuffer
rather than trying to call directly into the ioctl interface and
look up the handle returned.
- Use new setplane_internal() function to update the cursor plane
rather than calling through the ioctl interface. Note that since
we're no longer looking up an fb_id, no extra reference will be
taken here.
- Grab extra reference to fb under lock in !BO case to avoid issues
where racing userspace could cause the fb to be destroyed out from
under us after we grab the fb pointer.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
161d0dc1dc