On 4/8/21 8:35 AM, Daniel Vetter wrote:
On Tue, Apr 06, 2021 at 04:21:16PM -0300, Leandro Ribeiro wrote:
This patch is to emphasize how userspace should use the plane format list and the IN_FORMATS blob. The plane format list contains the formats that do not require modifiers, and the blob property has the formats that support modifiers.
Uh this is a very strong statement that I don't think is supported by kernel driver code. Where is this from.
Note that these are not disjoint sets. If a format supports modifiers but the driver can also handle it without a modifier, it should be present in both the IN_FORMATS blob property and the plane format list.
Same here ...
Yes, sorry. The wording was not good. To clarify:
I'm trying to document a good approach that userspace *can* (not must) take to be able to tell if a certain format can be used in the pre-modifier kernel uAPI or if it only works with modifiers.
The background is that we are reworking the way that Weston stores the formats and modifiers supported by the planes, and there were some wrong assumptions in the code related to what we can assume that the KMS driver supports.
We've discussed and decided to send a patch to raise a discussion and check if the conclusions that we've made were reasonable. And if not, what would be a better approach.
This is part of a MR in which we add support for the dmabuf-hints protocol extension in Weston. In sort, in Weston we store the formats and modifiers supported by the planes. Then we send them to the client and it may pick one of these format/modifier pairs to allocate its buffers, increasing the chances of its surface ending up in a plane.
Here are two commits of the MR that are related to this discussion:
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/544/diffs?com...
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/544/diffs?com...
Thanks!
I thought these two lists are 100% consistent. If not sounds like driver bugs that we need to maybe validate in drm_plane_init.
This is important for userspace, as there are situations in which we need to find out if the KMS driver can handle a certain format without any modifiers.
I don't think you can rely on this. No modifiers means implicit modifier, and the only thing that can give you such buffers is defacto mesa userspace drivers (since that all depends upon driver private magic, with maybe some kernel metadata passed around in private ioctls on the render node).
Maybe for more context, what's the problem you've hit and trying to clarify here? -Daniel
Leandro Ribeiro (2): drm/doc: document drm_mode_get_plane drm/doc: emphasize difference between plane formats and IN_FORMATS blob
drivers/gpu/drm/drm_plane.c | 4 ++++ include/uapi/drm/drm_mode.h | 22 ++++++++++++++++++++++ 2 files changed, 26 insertions(+)
-- 2.31.1