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). > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
