On 31/07/17 14:48, Laurent Pinchart wrote: >>> The comment about read lock is only valid when the plane is bound to the >>> crtc. In general this is not always the case. You can only peak at >>> plane->state when crtc->state->plane_mask & BIT(drm_plane_index(plane)) >>> is true. >>> >>> I think we might need -EDEADLK handling for getprop then, even though it's >>> not optimal. :( >> >> Well both the old an new way only worked because we grab all the locks >> unconditionally. And I'd really want to avoid get_prop being anything >> but a simple lookup. Unfortuantely that breaks omapdrm, so no idea >> what exactly to do here. >> >> In a way adding properties without standardizing them across drivers >> first was a really bad idea, because then we have disjoint sets of >> uapi expectations, and there's just no way to make that work. >> >> I guess one radical approach might be to make this the "standard", and >> just redirect rotation from the CRTC to the primary plane. >> >> Or omapdrm needs to duplicate the property properly, and update one if >> the other is set. I think that's probably the most workable approach. > > Maybe the first question we should answer is whether this hack is still needed > in the omapdrm driver. Tomi, do you know whether userspace still needs this ? The omap X driver uses legacy modesetting and the rotation property for the crtc. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
