From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
Subject: Re: [PATCH 1/4] drm: Add support for CRTC primary planes
Date: Tue, 4 Mar 2014 14:59:08 +0200
Message-ID: <20140304125908.GH3852@intel.com>
References: <1393539283-5901-1-git-send-email-matthew.d.roper@intel.com>
	<1393539283-5901-2-git-send-email-matthew.d.roper@intel.com>
	<CANq1E4RcD1qcj2X0bfhT9yL3De1dNcEj=-kW88455312KHe6jg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-path: <dri-devel-bounces@lists.freedesktop.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
	by gabe.freedesktop.org (Postfix) with ESMTP id D60FBFB69D
	for <dri-devel@lists.freedesktop.org>;
	Tue,  4 Mar 2014 04:59:11 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <CANq1E4RcD1qcj2X0bfhT9yL3De1dNcEj=-kW88455312KHe6jg@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Sender: dri-devel-bounces@lists.freedesktop.org
Errors-To: dri-devel-bounces@lists.freedesktop.org
To: David Herrmann <dh.herrmann@gmail.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
List-Id: dri-devel@lists.freedesktop.org

On Mon, Mar 03, 2014 at 07:24:04PM +0100, David Herrmann wrote:
> How can user-space distinguish primary-planes from others? With
> atomic-modesetting I can understand that there's no need to
> distinguish them, but without it, we need to know which planes not to
> use. Same problem for the possible_crtc field. The plane might work
> with other CRTCs, but for legacy modesetting we don't care as we have
> no API to use it.
> =

> I'd be nice to see somehow which primary plane is assigned to which
> crtc. But maybe this all is just not intended to be used without
> atomic-modesetting.
> =

> I like the proposal!

My take on this is that if the client has enable the new capbility,
it should not use the legacy cursor ioctls, nor should it specify
a framebuffer in the setcrtc ioctl. In fact I'd just return an error
if it does that.

But we still have the issue of figuring out what each plane can and
can't do. We need to expose that somehow, ideally in some form that's
not too hardware specific. So some kind of plane caps would be needed,
either as a separate ioctl or as read-only properties.

-- =

Ville Syrj=E4l=E4
Intel OTC