On Mon, Mar 03, 2014 at 09:45:53AM -0800, Matt Roper wrote:
On Mon, Mar 03, 2014 at 03:47:43PM +0000, Damien Lespiau wrote:
On Thu, Feb 27, 2014 at 02:14:40PM -0800, Matt Roper wrote:
Allow drivers to provide a drm_plane structure corresponding to a CRTC's primary plane. These planes will be included in the plane list for any clients setting the DRM_CLIENT_CAP_EXPOSE_PRIMARY_PLANES capability bit.
Signed-off-by: Matt Roper matthew.d.roper@intel.com
Two small notes here and comments inside:
In term of new API enabling and to make the tree bisectable, one needs to 1/ do the preparation work 2/ enable the API. In this case, I would split up the patch to make the ioctl bits independent and the last patch of the series.
I don't see a point in introducing the complexity to enable sprite and cursor planes independently from each other. So before enabling the new setcap() ioctl, could we also expose the cursor planes and call the capability "universal planes" or similar?
I'm not sure I follow what you're saying on this second point. Sprites (or overlays) are already exposed to userspace, so existing clients expect anything they receive via drmModeGetPlaneResources() to behave in the traditional manner. If we start throwing cursor planes into that list without hiding them behind a capability bit, existing userspace try to blindly use the cursors as full overlays without realizing that they may carry additional restrictions on size and such, which will lead to userspace breakage.
I mean, I don't see the point of having 2 separate calls to the SET_CAP ioctl() to enable both primary and cursor planes. I think we should have a single cap called "Universal planes" that expose both (which of course means we need to do the same work for cursor plane before the ioctl patch). This way we have fewer corner cases to care about.