Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757042Ab1CNUgJ (ORCPT ); Mon, 14 Mar 2011 16:36:09 -0400 Received: from mail-bw0-f46.google.com ([209.85.214.46]:58308 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756803Ab1CNUfy convert rfc822-to-8bit (ORCPT ); Mon, 14 Mar 2011 16:35:54 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fWCluW/JsXGklwNCfe/jEpR5xzpJzrVIEmPzdSh4WxIsbDXRHaMgSN0UJC8xuD1UYA BYCubLwLZV3gLVWxwxZMGrekSry4ec7BvBBYCt8QOapoSqIu5ZoVvuAoZCRg/zGdfoZq xaU2wdYgkN61rvzDOjgAzgcZKc/DZdwWGwXTg= MIME-Version: 1.0 In-Reply-To: <4D7E204E.7010303@stericsson.com> References: <201011251747.48365.arnd@arndb.de> <201011261224.59490.arnd@arndb.de> <20101205112813.GB12542@viiv.ffwll.ch> <4D7E204E.7010303@stericsson.com> Date: Mon, 14 Mar 2011 15:35:52 -0500 Message-ID: Subject: Re: [PATCH 09/10] MCDE: Add build files and bus From: Rob Clark To: Marcus Lorentzon Cc: Alex Deucher , Arnd Bergmann , Jimmy RUBIN , Dan JOHANSSON , Linus WALLEIJ , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" , Daniel Vetter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6922 Lines: 153 On Mon, Mar 14, 2011 at 9:03 AM, Marcus Lorentzon wrote: > On 03/12/2011 04:59 PM, Rob Clark wrote: >> >> On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter ?wrote: >> >>> >>> On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote: >>> >>>> >>>> This doesn't seem that different from the graphics chips we support >>>> with kms. ?I don't think it would require much work to use KMS. ?One >>>> thing we considered, but never ended up implementing was a generic >>>> overlay API for KMS. ?Most PC hardware still has overlays, but we >>>> don't use them much any more on the desktop side. ?It may be >>>> worthwhile to design an appropriate API for them for these type of >>>> hardware. >>>> >>> >>> Just fyi about a generic overlay api: I've looked a bit into this when >>> doing the intel overlay support and I think adding special overlay crtcs >>> that can be attached real crtcs gives a nice clean api. We could the >>> reuse >>> the existing framebuffer/pageflipping api to get the buffers to the >>> overlay engine. >>> >> >> btw, has there been any further thought/discussion on this topic.. >> I've been experimenting with a drm driver interface on the OMAP SoC. >> It is working well now for framebuffer type usage (mode setting, >> virtual framebuffer spanning multiple diplays, and those types of >> xrandr things).. ?the next step that I've started thinking about is >> overlay (or underlay.. the z-order is flexible) support.. >> >> I was thinking in a similar direction (ie. a special, or maybe not so >> special, sort of crtc) and came across this thread, so I thought I'd >> resurrect the topic. >> >> In our case, most of the CRTCs in our driver could be used either with >> (A)RGB buffers as a traditional framebuffer, or with a few different >> formats of YUV as video under/overlays. ?So if you had one display >> attached, you might only use one CRTC for traditional GUI/gfx layer, >> and the rest are available for video. ?If you had two displays, then >> you'd steal one of the video CRTCs and use it for the gfx layer on the >> second display. ?And so on. >> >> > > We have similar HW and are also interested in finding some common ground for > overlays in KMS. Just as you describe, we have no hard connection between a > CRTC and output. Instead we only have overlays. Normal gfx use case is then > of course one of these overlays dedicated to one display. And when adding > video overlays, we also prefer YUV "underlays" with fullscreen ARGB gfx on > top. > > The problem with mapping this to the CRTCs in KMS today, is that there is no > differentiation between framebuffer width/height and crt width/height. And > of course YUV formats and fb position etc are missing. > > One advantage of the set CRTC ioctl is that all information needed to switch > mode is contained in one atomic set mode ioctl. So we have to think about if > we want a new more advanced set crtc including overlay config. Or if we want > to split mode setup into several requests. And then we must decide if > multiple setup ioctls will need some type of "commit" to get the atomic mode > switch we have today. For example I don't want to have to do a set_crtc > enabling blending without overlay being setup. It should be just as glitch > free as KMS is today. >> >> Rough thinking: >> + add some 'caps' to the CRTC to indicate whether it can handle YUV, >> ARGB, scaling >> + add an x/y offset relative to the encoder (as opposed to the >> existing x/y offset relative to the framebuffer) >> + add a z-order parameter >> >> > > Exactly what I would like to have. Especially the caps for scaling, since we > have one HW that can't do scaling. >> >> Not sure about intel hw if it is supporting clip-rects.. if so, maybe >> need to add something about that. ?In our case we jut put the video >> behind the gfx layer and use the alpha channel in the gfx framebuffer >> to clip/blend rather than using clip-rects. >> >> > > If this is common ground, I would like to have one clip rect per > CRTC/overlay to enable framebuffers larger than overlay viewport. That makes > it easier to reuse a large buffer for multiple overlays/framebuffers without > having to stress memory management driver. But this is just a "nice to have" > feature. Maybe this can be mapped to stride/start address mappings on HW > without clip rect. But that will probably include alignment requirements on > position and size. Good point, I had overlooked that but we do have same requirement for cropping as well.. although in the crtc we already specify an x/y offset within the drm_framebuffer that the crtc is attached to.. so I guess if we have an input width/height (output is implied I guess by the encoder/connector) then we should be fine for cropping Although in some cases top/left crop offset could be changing frame by frame (think use cases like zero-copy video stabilization or pan/scan) so might be nice to have a way to specify new x/y offset when flipping. I guess that would be an extension/change to existing page flip ioctl. BR, -R >>> >>> The real pain starts when we want format discovery from userspace with >>> all >>> the alignement/size/layout constrains. Add in tiling support and its >>> almost impossible to do in a generic way. But also for kms userspace >>> needs >>> to know these constrains (implemented for generic use in libkms). I favor >>> such an approach for overlays, too (if it ever happens) - i.e. a few >>> helpers in libkms that allocate an appropriate buffer for a given format >>> and size and returns the buffer, strides and offsets for the different >>> planes. >>> >> >> hmm, I guess I know about the OMAP display subsystem, and it's overlay >> formats/capabilities.. but not enough about other hw to say anything >> intelligent here. ?But I guess even if we ignore the format of the >> data in the buffer, at least the APIs to setup/attach overlay CRTCs at >> various positions could maybe be something we can start with as a >> first step. ?At least standardizing this part seems like a good first >> step. ?But I'm definitely interested if someone has some ideas. >> >> > > Yes, so we could try and find some common ground and add support for that. > But still enable drivers to extend that with the features where we find no > common ground. Just as GEM doesn't provide allocation ioctl, only free. > > And in the end we have to see if the common ground is enough to actually > build an application on. If not, there's not much use for a partial common > API. Maybe that's why there's no overlay API in KMS tiday? > > Maybe vendor libkms can be used to fill in the gaps? > > /BR > /Marcus > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/