10/25/2011 08:13 PM, Jesse Barnes 쓴 글:
On Tue, 25 Oct 2011 19:47:13 +0900
Joonyoung Shim<jy0922.shim@xxxxxxxxxxx> 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?
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
