Hi, 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. 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. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
