All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Lespiau <damien.lespiau@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm: Add support for CRTC primary planes
Date: Mon, 3 Mar 2014 17:56:43 +0000	[thread overview]
Message-ID: <20140303175643.GB4351@strange.amr.corp.intel.com> (raw)
In-Reply-To: <20140303174553.GA27798@intel.com>

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.

-- 
Damien

  reply	other threads:[~2014-03-03 17:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27 22:14 [PATCH 0/4] Expose primary planes to userspace Matt Roper
2014-02-27 22:14 ` [PATCH 1/4] drm: Add support for CRTC primary planes Matt Roper
2014-03-03 15:47   ` Damien Lespiau
2014-03-03 17:45     ` Matt Roper
2014-03-03 17:56       ` Damien Lespiau [this message]
2014-03-03 18:24   ` David Herrmann
2014-03-04 12:59     ` Ville Syrjälä
2014-02-27 22:14 ` [PATCH 2/4] drm: Add plane type property Matt Roper
2014-02-27 22:39   ` Rob Clark
2014-02-27 23:24     ` Matt Roper
2014-02-28  4:03       ` Rob Clark
2014-03-03 16:02         ` Damien Lespiau
2014-03-04 12:38       ` Daniel Vetter
2014-02-27 22:14 ` [PATCH 3/4] drm/i915: Rename similar plane functions to avoid confusion Matt Roper
2014-02-27 22:14 ` [PATCH 4/4] drm/i915: Register primary plane for each CRTC Matt Roper
2014-03-04 13:15   ` [Intel-gfx] " Ville Syrjälä

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140303175643.GB4351@strange.amr.corp.intel.com \
    --to=damien.lespiau@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=matthew.d.roper@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.