Re: [PATCH v2 1/1] drm/doc: document drm_mode_get_plane

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux