10/25/2011 08:13 PM, Jesse Barnes 쓴 글:
On Tue, 25 Oct 2011 19:47:13 +0900 Joonyoung Shimjy0922.shim@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, planesshould 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?