On Mon, Mar 14, 2011 at 9:03 AM, Marcus Lorentzon <marcus.xm.lorentzon@xxxxxxxxxxxxxx> wrote: > On 03/12/2011 04:59 PM, Rob Clark wrote: >> >> On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter<daniel@xxxxxxxx> 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 > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
