On Fri, Dec 22, 2017 at 05:15:05PM +0200, Peter Ujfalusi wrote: > 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. 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). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
