DRM planes and new fb creation ioctl

[Jesse Barnes]

On Tue, 25 Oct 2011 19:47:13 +0900
Joonyoung Shim <jy0922.shim at samsung.com> wrote:
> 10/25/2011 06:46 PM, Jesse Barnes 쓴 글:
> > I've given up waiting for someone to implement support for these
> > ioctls on another platform before they're merged, but I have
> > received a lot of feedback on the interfaces, and it sounds like
> > they're ok.  I've also fixed all the remaining issues I'm aware of
> > on SNB platforms and things are working well, so I'm just going to
> > push them out.  (Note IVB support is still missing a few bits for
> > scaling and such; I'll fix those up when I get back home and can
> > test on IVB again.)
> >
> > One change you may notice from the last set is that I've removed the
> > 'zpos' parameter.  Plane blending and z ordering is very chipset
> > specific (it even varies between Intel chipsets), so exposing it
> > through a device specific ioctl is probably a better plan.
> 
> But i think zpos is essential parameter of plane. If plane doesn't
> support it, drm driver cannot know user wants to use which overlay,
> so i wonder what it meant DRM_IOCTL_MODE_SETPLANE zpos is absent .

Setplane is just for attaching a new fb.  The order, keying, or
whatever else your plane blender can support can be set with a device
specific ioctl before or after the setplane call (probably before to
avoid any flashing or bad frames).

> If use device specific ioctl, should implement device specific ioctl
> for DRM_IOCTL_MODE_SETPLANE?

You could if you needed, but I don't think it's strictly necessary.

> >    By default, planes
> > should just overlay the primary plane; a device specific ioctl (none
> > available yet, but I have some planned for i915) can provide more
> > flexibility.
> 
> Could you explain what is the primary plane? Is it same as the overlay
> handled by crtc? It confuses a bit when one overlay is handled by crtc
> and plane at the same time.

Yeah, it is a little confusing.  When I refer to the primary, I'm
referring to the plane bound to the CRTC.  I'm fine if someone wants to
break that out, I think it would make sense.  I just didn't want to
write the compat code that would be required for that scheme. :)  But
these patches definitely don't preclude it, and I don't think these
interfaces will need changes if we ever move to a pipe/plane split at
the userland level.

Thanks,
Jesse