On 24/04/17 17:00, Laurent Pinchart wrote: > Hi Tomi, > > On Monday 24 Apr 2017 12:40:10 Tomi Valkeinen wrote: >> On 15/04/17 12:16, Laurent Pinchart wrote: >>> The DRM core implements a standard "zpos" property to control planes >>> ordering. The omapdrm driver implements a similar property named >>> "zorder". Although we can't switch to DRM core handling of the "zpos" >>> property for backward compatibility reasons, we can store the zorder >>> value in the drm_plane_state zpos field, saving us from having to >>> implement custom plane state handling. >> >> I'm fine with the zpos change, but I'd like to keep the omap_plane_state >> around. It'll be empty after this patch, but we have a bunch of >> properties we need to add. Some can be added as common DRM properties, >> but perhaps not all. It's so much easier to handle those patches if the >> plumbing is there already, instead of adding it back. > > How about reverting the needed parts of this patch at that time then ? I think > it would be better than keeping useless code around until a hypothetical time > when it will be needed. I kind of agree, but based on my experience, I disagree =). We have a bunch of HW properties for both crtcs and planes which are not supported in mainline. I have patches for those. It's difficult to upstream them, because the aim should be to get common properties. Creating common properties is Hard. So I need to carry those patches, maybe for a long time, which means rebasing, which means gazillion conflicts if the mainline version doesn't have the omap custom state for crtc and plane. In the minimum, the change for the zorder and the change that removes the omap_plane_state should be separate. Then the removal patch can be reverted, and the amount of conflicts drops to half a gazillion. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
