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: Tue, 26 Apr 2011 08:16:02 -0700 Message-ID: <20110426081602.0cf170bd@jbarnes-desktop> References: <20110425151220.2f5dc17a@jbarnes-desktop> <20110425162216.529c126c@jbarnes-desktop> <20110426110130.24cdf23d@lxorguk.ukuu.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by gabe.freedesktop.org (Postfix) with SMTP id 7CEE89EEB2 for ; Tue, 26 Apr 2011 08:16:07 -0700 (PDT) In-Reply-To: <20110426110130.24cdf23d@lxorguk.ukuu.org.uk> 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: Alan Cox Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Tue, 26 Apr 2011 11:01:30 +0100 Alan Cox wrote: > > 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.). > > Rather than re-inventing enough wheels to run a large truck would it not > make sense to make hardware sourced overlays Video4Linux objects in their > entirity so you can just say "attach V4L object A as overlay B" > > That would provide format definitions, provide control interfaces for > the surface (eg for overlays of cameras such as on some of the Intel > embedded and non PC devices), give you an existing well understood API. > > For some hardware you are going to need this integration anyway so that > you can do things like move a GEM object which is currently a DMA target > of a capture device (as well as to fence it). > > For a software surface you could either expose it as a V4L object that > is GEM or fb memory backed or at least use the same descriptions so that > the kernel has a consistent set of descriptions for formats and we don't > have user libraries doing adhoc format translation crap. > > A lot of capture hardware would map very nicely onto GEM objects I > suspect and if you want to merge live video into Wayland it seems a > logical path ? Thanks Alan, of course that's a good idea, I'll see about integrating the two. -- Jesse Barnes, Intel Open Source Technology Center