[PATCH 0/4] Expose primary planes to userspace (original) (raw)
Matt Roper matthew.d.roper at intel.com
Thu Feb 27 14:14:39 PST 2014
- Previous message: [RFC] drm/ttm: Add optional support for two-ended allocation
- Next message: [PATCH 1/4] drm: Add support for CRTC primary planes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
One of the stepping stones on the way to atomic/nuclear operation is to expose CRTC primary planes (and eventually cursor planes too) to userspace in the same manner that sprites/overlays are today. This patch series takes the first step of allowing drivers to register a CRTC's primary plane with the DRM core; the core will then include this primary plane in the plane list returned to userspace for clients that set an appropriate client capability bit.
This patchset isn't terribly interesting on its own; you can call the traditional KMS plane API's (like SetPlane) on the CRTC's primary plane now, but this doesn't really allow us to do anything we couldn't before. The real goal here is to pave the way for a cleaner API as we move toward atomic/nuclear updates and the eventual property-ification of all settings.
This patch set only updates the i915 driver at the moment, but drivers that aren't updated should continue to function as they have in the past (i.e., the plane list returned to userspace will contain only sprite/overlay planes, regardless of whether the userspace client sets the capability bit or not).
The patch set is organized as follows:
Patch 1 updates the DRM core with general support for primary planes, adding the interface for drivers to register primary planes, and a client cap bit that determines whether these primary planes should be returned to userspace clients.
Patch 2 adds a new "plane type" property to plane objects which allow userspace to distinguish primary planes (and probably cursor planes in the future) from regular sprite/overlay planes.
Patch 3 simply renames the i915 'update_plane' functions in intel_display.c to 'update_primary_plane.' This change just helps prevent confusion between these functions and the similarly named sprite-related ones in intel_sprite.c. We also rename the intel_disable_primary_plane() function to prevent confusion with a new intel_primary_plane_disable() function added in patch #4.
Patch 4 updates the i915 driver to create a primary plane for each CRTC at CRTC initialization time and register it with the DRM core. The setplane handler for primary planes simply performs an MMIO flip of the provided framebuffer.
Matt Roper (4): drm: Add support for CRTC primary planes drm: Add plane type property drm/i915: Rename similar plane functions to avoid confusion drm/i915: Register primary plane for each CRTC
drivers/gpu/drm/drm_crtc.c | 200 ++++++++++++++++++++++++++++++++++- drivers/gpu/drm/drm_ioctl.c | 5 + drivers/gpu/drm/i915/i915_drv.h | 5 +- drivers/gpu/drm/i915/intel_display.c | 132 ++++++++++++++++++++--- include/drm/drmP.h | 2 + include/drm/drm_crtc.h | 12 +++ include/uapi/drm/drm.h | 8 ++ include/uapi/drm/drm_mode.h | 3 + 8 files changed, 343 insertions(+), 24 deletions(-)
-- 1.8.5.1
- Previous message: [RFC] drm/ttm: Add optional support for two-ended allocation
- Next message: [PATCH 1/4] drm: Add support for CRTC primary planes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]