On Mon, Oct 15, 2018 at 10:29 AM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote: > On Fri, Oct 12, 2018 at 06:47:13PM +0200, Paul Kocialkowski wrote: > > I'm looking at the sun4i DRM driver these days (especially for > > mainlining the VPU tiled format support through the frontend). > > > > The way things are done currently, all the possibly-supported plane > > formats are listed in sun4i_backend_layer_formats and exposed as-is to > > userspace for every plane. However, some of these formats cannot be > > used on all planes at the same time and will be rejected when checking > > the atomic commit. > > > > I find this a bit confusing from a userspace perspective. > > > > Not all constraints can be provided to userspace (e.g. the number of > > planes we can effectively scale), but when it comes to formats, we have > > that possibility. So perhaps it would make sense to only enumerate > > formats as many times as we can support them. > > > > For instance, it could look like: > > # plane 0: primary, RGB only > > # plane 1: overlay, RGB + backend YUV formats > > # plane 2: overlay, RGB + frontend YUV formats > > # plane 3: overlay, RGB only > > > > That's not perfect either, because e.g. requesting a scaled RGB plane > > will require the frontend and thus make it impossible to use the > > frontend YUV formats that would still be described. But it feels like > > it would be closer to representing hardware capabilities than our > > current situation. > > That's really arguable. The hardware capabilities are that you can use > any of those formats or features, on any plane, *but* on only one > plane at the same time. What you describe isn't closer to it, it's > just a way to workaround the issue we are facing (ie being able to > show those constraints to userspace), and an imperfect workaround. > > > I am really not sure about the DRM subsystem policy about this, though. > > Perhaps it was already decided that it's fine to deal with everything > > at commit checking time and report more formats than the hardware can > > really handle. > > It doesn't really matter what the DRM policy is here. Any change in > the direction you suggest would be a regression from the userspace > point of view and therefore would have to be reverted. How exactly can this cause a regression? Do you have some userspace that card-codes it's allocation of planes, which would then fail here and worked beforehand? > IIRC Weston tries to discover those constraints by brute-forcing > atomic_check and figuring out a combination that works, and we would > surely benefit some kind of API to expose composition constraints. The current hints we have is to limit the features each plane exposes. Currently there's no proposal to do stuff like "only x of y planes can do $feature" at all. So yeah, Paul's idea doesn't seem entirely out of hand to me, and for the "bug regressions" we need a concrete example of what will break. Since we're fine-tuning the drm api all the time, within the limits of what userspace expects :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
