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. > 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. -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
