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

[Peter Ujfalusi]

Hi,

On 2017-12-22 12:12, Ville Syrjälä wrote:
> On Fri, Dec 22, 2017 at 11:16:47AM +0200, Tomi Valkeinen wrote:
>> On 21/12/17 17:12, Ville Syrjälä wrote:
>>
>>>> If the userspace knows this, then it knows which primary plane is for
>>>> which crtc, right?
>>>>
>>>> And if it doesn't know this, then the userspace cannot associate any
>>>> plane to any crtc (except what it configures itself).
>>>>
>>>> So... If using legacy modesetting (and non-universal planes), there's no
>>>> problem, primary planes are fixed and at low zpos. If using atomic
>>>> modesetting and universal planes, there's really no (default)
>>>> association between planes and crtcs, and "primary plane" doesn't have
>>>> much meaning. Is that correct?
>>>>
>>>> If so... Then I guess the atomic modesetting client essentially randomly
>>>> picks which plane it uses as a "root plane" (if it even needs such), and
>>>> which planes as overlay planes? If that's the case, then this patch
>>>> doesn't quite fix the issue...
>>>
>>> I'm not sure anyone has really thought how userspace would/should assign
>>> planes to crtcs. My only idea so far has been the crtc and their
>>> preferred primary planes should be registered in the same order. But
>>> someone should then also implement that same policy in userspace when
>>> it's trying to figure out which plane to use. There are other
>>> heuristics it should probably use, like preferring to pick a primary
>>> plane for any fullscreen surface.
>>>
>>> I guess from functional point of view it shouldn't matter which plane
>>> you pick as long as the plane's user visible capabilities are
>>> sufficient. But there might be user invisible power saving features and
>>> whatnot that only work with specific planes. So from that point of view
>>> maybe the order in which the planes get registered is important. Or we
>>> could maybe come up with some kind of plane usage hints in the uapi
>>> which could help userspace decide?
>>
>> I was thinking about this, and... maybe there isn't even any problem (at 
>> least for OMAP). So lets say we set the default plane zpos to the plane 
>> index, and that the primary planes are reserved first (i.e. have lower 
>> zpos than overlay planes).
>>
>> We have three different cases:
>>
>> Legacy modesetting: No problems, primary plane is always at the bottom. 
>> If the userspace uses 2+ overlay planes, it can expect the zpos to be 
>> based on the plane id, or it can set the zpos.
>>
>> Atomic+Universal, the application uses one primary plane, and zero or 
>> more overlay planes: No problems here, the situation is the same as for 
>> legacy.
>>
>> Atomic+Universal, the application uses more than one primary plane, and 
>> zero or more overlay planes: in this case the app _has_ to manage zpos, 
>> because using two primary planes in a single screen, and expecting it to 
>> work by default, doesn't make sense.
>>
>> If the above "rules" are valid, then there's no need for this patch.
>>
>> But one question I don't have a good answer is that why would we want to 
>> normalize the zpos, instead of returning an error? If the above rules 
>> are valid, I think returning an error is better than normalizing and 
>> hiding the bad configuration.
> 
> IIRC I argued against the normalization, but some people really
> wanted it for whatever reason.

OK, please ignore this series, I'll send a patch instead next year.

- Péter

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