From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [RFC] drm: add overlays as first class KMS objects
Date: Mon, 25 Apr 2011 16:22:16 -0700
Message-ID: <20110425162216.529c126c@jbarnes-desktop>
References: <20110425151220.2f5dc17a@jbarnes-desktop>
	<yun39l5hqgt.fsf@aiko.keithp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org>
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com
	[67.222.54.6])
	by gabe.freedesktop.org (Postfix) with SMTP id 7069F9E947
	for <dri-devel@lists.freedesktop.org>;
	Mon, 25 Apr 2011 16:22:19 -0700 (PDT)
In-Reply-To: <yun39l5hqgt.fsf@aiko.keithp.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+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: Keith Packard <keithp@keithp.com>
Cc: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org

On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard <keithp@keithp.com> wrote:

> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> 
> > Overlays are a bit like half-CRTCs.  They have a location and fb, but
> > don't drive outputs directly.  Add support for handling them to the core
> > KMS code.
> 
> Are overlays/underlays not associated with a specific CRTC? To my mind,
> overlays are another scanout buffer associated with a specific CRTC, so
> you'd create a scanout buffer and attach that to a specific scanout slot
> in a crtc, with the 'default' slot being the usual graphics plane.

Yes, that matches my understanding as well.  I've deliberately made the
implementation flexible there though, under the assumption that some
hardware allows a plane to be directed at more than one CRTC (though
probably not simultaneously).

Arguably, this is something we should have done when the
connector/encoder split was done (making planes in general first class
objects).  But with today's code, treating a CRTC as a pixel pump and a
primary plane seems fine, with overlays tacked onto the side as
secondary pixel sources but tied to a specific CRTC.

-- 
Jesse Barnes, Intel Open Source Technology Center