Hi Daniel, On Tuesday, 9 January 2018 14:42:55 EET Daniel Vetter wrote: > On Fri, Dec 22, 2017 at 05:15:05PM +0200, Peter Ujfalusi wrote: > > 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. > > So now we end up with a bunch of kms drivers that normalize zpos, and a > bunch of others which rejects duplicated zpos. > > That sounds even worse. Can we pls try to be consistent (even if it turns > out to be a not-so-great uapi decision, it's uapi, so let's not make > things worse by making it inconsistent). For what it's worth, I'd tend to disallow duplicate zpos values. That forces userspace to user atomic and to handle zpos explicitly, and that's exactly why it's my preference as not handling zpos explicitly in userspace will lead to random behaviour at best. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
