On Mon, Mar 03, 2014 at 07:24:04PM +0100, David Herrmann wrote: > How can user-space distinguish primary-planes from others? With > atomic-modesetting I can understand that there's no need to > distinguish them, but without it, we need to know which planes not to > use. Same problem for the possible_crtc field. The plane might work > with other CRTCs, but for legacy modesetting we don't care as we have > no API to use it. > > I'd be nice to see somehow which primary plane is assigned to which > crtc. But maybe this all is just not intended to be used without > atomic-modesetting. > > I like the proposal! My take on this is that if the client has enable the new capbility, it should not use the legacy cursor ioctls, nor should it specify a framebuffer in the setcrtc ioctl. In fact I'd just return an error if it does that. But we still have the issue of figuring out what each plane can and can't do. We need to expose that somehow, ideally in some form that's not too hardware specific. So some kind of plane caps would be needed, either as a separate ioctl or as read-only properties. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
