From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [RFC] drm: add overlays as first class KMS objects Date: Mon, 25 Apr 2011 17:33:25 -0700 Message-ID: <20110425173325.7a9c8fc1@jbarnes-desktop> References: <20110425151220.2f5dc17a@jbarnes-desktop> <20110425162216.529c126c@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.39.38]) by gabe.freedesktop.org (Postfix) with SMTP id 8C8F99E70A for ; Mon, 25 Apr 2011 17:33:29 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: Alex Deucher Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Mon, 25 Apr 2011 20:28:20 -0400 Alex Deucher wrote: > On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes = wrote: > > On Mon, 25 Apr 2011 16:16:18 -0700 > > Keith Packard wrote: > > > >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes wrote: > >> > >> > Overlays are a bit like half-CRTCs. =A0They have a location and fb, = but > >> > don't drive outputs directly. =A0Add support for handling them to th= e 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 sl= ot > >> in a crtc, with the 'default' slot being the usual graphics plane. > > > > Yes, that matches my understanding as well. =A0I've deliberately made t= he > > 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). > = > A lot of older hardware had one overlay that could be sourced to any > crtc, just not simultaneously. The tricky part is the formats and > capabilities: alpha blending, color/chromakey, gamma correction, etc. > Even the current crtc gamma stuff is somewhat lacking in in terms of > what hardware is capable of (PWL vs. LUT, user defined conversion > matrices, gamut remapping, etc.). Right, this implementation allows an overlay to be tied to any crtc listed in the possible_crtcs mask (matching the other possible_* fields), but only one at a time. I think that's fairly common. Agree about formats and capabilities. I think enumerating available formats is best, perhaps making that a driver specific array if we can't agree on a common set. Dealing with color correction could also be driver specific; once the client has an overlay id it can use driver specific ioctls to get/set specifics. -- = Jesse Barnes, Intel Open Source Technology Center