DRM planes and new fb creation ioctl

[Joonyoung Shim]

10/25/2011 08:13 PM, 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).
>

OK, i see.

Thanks.

>> 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.

Could you have the policy about fb of overlay? For example, user
attaches the fb of plane to the overlay already using by CRTC, then
output of overlay will be changed to the fb of plane from fb of CRTC.
And if user detaches the fb of plane, the overlay again should output
the fb of CRTC? or just be disabled?