On Fri, 23 Apr 2021 18:30:33 -0300 Leandro Ribeiro leandro.ribeiro@collabora.com wrote:
On 4/23/21 8:11 AM, Pekka Paalanen wrote:
On Thu, 22 Apr 2021 15:10:04 -0300 Leandro Ribeiro leandro.ribeiro@collabora.com wrote:
Add a small description and document struct fields of drm_mode_get_plane.
Signed-off-by: Leandro Ribeiro leandro.ribeiro@collabora.com
include/uapi/drm/drm_mode.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index a5e76aa06ad5..3e85de928db9 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -312,16 +312,32 @@ struct drm_mode_set_plane { __u32 src_w; };
+/**
- struct drm_mode_get_plane - Get plane metadata.
- Userspace can perform a GETPLANE ioctl to retrieve information about a
- plane.
- */
struct drm_mode_get_plane {
/** @plane_id: Object ID of the plane. */ __u32 plane_id;
/** @crtc_id: Object ID of the current CRTC. */ __u32 crtc_id;
/** @fb_id: Object ID of the current fb. */ __u32 fb_id;
/** @possible_crtcs: Bitmask of CRTC's compatible with the plane. */
This should probably explain what the bits in the mask correspond to. As in, which CRTC does bit 0 refer to, and so on.
What about:
"possible_crtcs: Bitmask of CRTC's compatible with the plane. CRTC's are created and they receive an index, which corresponds to their position in the bitmask. CRTC with index 0 will be in bit 0, and so on."
This would still need to explain where can I find this index.
__u32 possible_crtcs;
- /** @gamma_size: Size of the legacy gamma table. */
What are the units? Entries? Bytes?
The number of entries. I'll update to "gamma_size: Number of entries of the legacy gamma lookup table" in the next version.
Sounds good!
Thanks, pq
__u32 gamma_size;
- /** @count_format_types: Number of formats. */ __u32 count_format_types;
- /**
* @format_type_ptr: Pointer to ``__u32`` array of formats that are
* supported by the plane. These formats do not require modifiers.
I wonder if the "do not require modifiers" is again going too far in making a difference between this list and IN_FORMATS?
Yes that's true, I'll drop this phrase.
__u64 format_type_ptr;*/
};
Other than those, looks like a significant improvement to me.
Thanks, pq
-- 2.31.1
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel