[PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos

Tomi Valkeinen tomi.valkeinen at ti.com
Thu Dec 21 13:44:56 UTC 2017

On 21/12/17 14:55, Ville Syrjälä wrote:
> On Thu, Dec 21, 2017 at 02:11:00PM +0200, Peter Ujfalusi wrote:
>> Make sure that the primary plane will get normalized_zpos=0 if it's zpos is
>> set to 0, avoiding other planes to be placed in the background.
> Can you describe the actual "bad" configuration?
> Without knowing the details this looks like it's making things
> more complicated for no particularly good reason. If you're worried
> about clients that don't set zpos, then I think you should just
> assign the default zpos values better and/or allocate the planes
> in a better order. But it's definitely possible I'm missing the
> reason why you're doing this.

Let's say we have two displays and two planes. First display will use 
crtc0 and plane0 as primary plane, the second display crtc1, plane1. The 
zpos of primary planes will be set to 0 by default.

The userspace wants to use the second display, with an overlay plane. So 
it takes the plane0 and moves it to crtc1. Now the second display has 
two planes with zpos 0, and normalize_zpos will fix it according to the 
plane id, i.e. the primary plane of the second display will be on top of 
the "overlay" plane.

I don't think other default zpos values and/or allocating planes in 
better order can solve this.

If the userspace is required to understand and set zpos, then this patch 
is not needed. But at least in my test scripts I've hit this a few times =).


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

More information about the dri-devel mailing list