Message-ID: <AANLkTimV3=VS1moXOt07d1XRJ72Sr6AVyUa6GFFJBX6D@mail.gmail.com>
Date:	Mon, 14 Mar 2011 15:35:52 -0500
From:	Rob Clark <robdclark@...il.com>
To:	Marcus Lorentzon <marcus.xm.lorentzon@...ricsson.com>
Cc:	Alex Deucher <alexdeucher@...il.com>,
	Arnd Bergmann <arnd@...db.de>,
	Jimmy RUBIN <jimmy.rubin@...ricsson.com>,
	Dan JOHANSSON <dan.johansson@...ricsson.com>,
	Linus WALLEIJ <linus.walleij@...ricsson.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH 09/10] MCDE: Add build files and bus

On Mon, Mar 14, 2011 at 9:03 AM, Marcus Lorentzon
<marcus.xm.lorentzon@...ricsson.com> wrote:
> On 03/12/2011 04:59 PM, Rob Clark wrote:
>>
>> On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter<daniel@...ll.ch>  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists