On 21/12/17 16:20, Ville Syrjälä wrote:
On Thu, Dec 21, 2017 at 03:44:56PM +0200, Tomi Valkeinen wrote:
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.
Hmm. True. OTOH this messes up the simple "plane id is used to resolve
zpos conflicts" logic.
Also since you have multiple primary planes on the same crtc, which
primary plane is the "real primary" for the crtc? How would userspace
even determine that? I guess the rule could be that the primary planes
have to be registered in the same order as the crtcs?
Hmm, true.
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 =).
I think it would be nice if we can just make it a rule that any
userspace that moves planes between crtcs has to know about zpos.
Otherwise it's pretty much pure luck what stacking order you would
get.
Yes, but how does the userspace know when it is moving planes between crtcs?
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...
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
