DRM planes and new fb creation ioctl
jbarnes at virtuousgeek.org
Tue Oct 25 04:13:26 PDT 2011
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.
More information about the dri-devel