Re: [RFC] Updated plane support v3

[Rob Clark <robdclark@gmail.com>]

On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes <jbarnes@virtuousgeek.org> 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?

Or would/could a drm_plane also be used for main layer instead of
crtc->fb?  In this case, either userspace would have to know (which
doesn't seem like a good idea for things like plymouth which use drm
interface a bit generically).  Or the driver would have to internally
automatically hook up a drm_plane if it sees that userspace hasn't
done this.

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.

BR,
-R

> Thanks,
> Jesse
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>