On Tue, Jun 21, 2011 at 11:19 AM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 21 Jun 2011 06:21:11 -0500 > Rob Clark <robdclark@xxxxxxxxx> wrote: > >> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: >> > This version adds both source and dest rect params to the set_plane >> > ioctl, and makes the source fixed point to support hardware that needs >> > it. >> > >> > I haven't changed the name of the SNB implementation yet (per Chris's >> > suggestions) but will before it gets upstream. >> > >> > I'd be interested to see whether these interfaces will work for other >> > hardware, so please take a close look at them and ideally implement them >> > on your hardware to make sure (see my userspace example code from >> > earlier posts if you want something to crib from). >> >> Cool, thanks for this >> >> I'm just thinking through how I'd implement the driver part in omap >> drm driver.. so please bear with me if I'm misunderstanding.. >> >> In particular I'm thinking about being able to use a given video pipe >> (basically like a dma channel) as either framebuffer layer or overlay >> at various points in time, depending on how many displays are >> attached. Is the idea to use drm_plane *only* for overlay layer, and >> still use crtc->fb for the normal framebuffer layer? > > Given the structure of the current KMS API, a CRTC implies a plane of > some sort, but I don't think the driver is restricted to using the same > plane for a given CRTC forever; it could allocate and switch them > around depending on usage, with planes beyond what's currently > associated with the CRTC exposed through this interface. The awkward thing is how do you express to userspace that if it isn't using some CRTC(s) that it has an extra plane(s) available, if each crtc even though it is not enabled, is assumed to consume a plane (video pipe).. That said if OMAP is the only hw like this, one possible solution is that you just need to have userspace know.. ie. the main one taking advantage of this feature would be the xorg driver, and it already knows what DRM driver it is talking to. Generic things like splash screen won't need to be using all the video planes. But I'm at least under the impression that some of the other SoC's have similar flexibility to use video planes as either primary or overlay layers. So I figure it is at least worth trying to handle this in a more generic way if it doesn't cause too much ugliness to KMS core. >> I was thinking perhaps that if we let userspace DRM_IOCTL_MODE_SETCRTC >> pass in -1 for fb_id, followed by one or more >> DRM_IOCTL_MODE_SETPLANE's, to set things up the "new" way (explicitly >> specify the drm_plane's). Or if _SETCRTC passes in a valid fb_id, we >> know it is the old way, and driver automatically picks a drm_plane. > > Yeah that might work; we'd probably want a new GETPARAM flag to > indicate support for this... The tough part is doing it in such a way > that we don't break existing userspace. fwiw, Daniel and I discussed a bit on IRC earlier today, and he had an interesting idea about having a simple drm_plane shim+helpers to keep things similar for existing drivers. I think it should be possible to support both old and new userspace semantics this way without too much if(driver_features & SUPPORTS_PLANES) sort of stuff. BR, -R _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
