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. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
