On 4/23/21 8:11 AM, Pekka Paalanen wrote:
> On Thu, 22 Apr 2021 15:10:04 -0300
> Leandro Ribeiro <leandro.ribeiro@xxxxxxxxxxxxx> wrote:
>
>> Add a small description and document struct fields of
>> drm_mode_get_plane.
>>
>> Signed-off-by: Leandro Ribeiro <leandro.ribeiro@xxxxxxxxxxxxx>
>> ---
>> 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."
>> __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.
>> __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@xxxxxxxxxxxxxxxxxxxxx
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
