STRUCT DRM_MODE_GET_PROPERTY(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct drm_mode_get_property β€” Get property metadata ✨

okay bestie, welcome to the Kernel API Manual, section 9, and honestly? this one's a little iconic. it's struct drm_mode_get_property, and it's literally the answer to "wait, what is this property?" β€” let's get into it πŸŽ€


πŸ¦‹ NAME πŸ¦‹

struct drm_mode_get_property β€” Get property metadata.


🌸 SYNOPSIS 🌸

struct drm_mode_get_property {
    __u64 values_ptr;
    __u64 enum_blob_ptr;
    __u32 prop_id;
    __u32 flags;
    char name[DRM_PROP_NAME_LEN];
    __u32 count_values;
    __u32 count_enum_blobs;
 };

✨ Members ✨

so here's the whole cast, no cap β€” every field, doing its thing πŸ’–

🫢 the fields

  • values_ptr β€” a pointer to a __u64 array. that's it, that's the field. it holds the values ✨
  • enum_blob_ptr β€” a pointer to a struct drm_mode_property_enum array. the enum side of the story πŸ’œ
  • prop_id β€” the object ID of the property you want to retrieve. you, the caller, set this one. main character energy πŸ”₯
  • flags β€” a DRM_MODE_PROP_* bitfield. for what all the flags mean, go peek at drm_property.flags β€” that's where the definitions live πŸ‘‘
  • name β€” the symbolic property name. user-space, this is literally your field for recognizing properties, use it πŸ’…
  • count_values β€” the number of elements in values_ptr. keep it honest πŸ“
  • count_enum_blobs β€” the number of elements in enum_blob_ptr. same energy, different array 🌈

🧚 DESCRIPTION 🧚

okay so the whole point: user-space can do a GETPROPERTY ioctl to retrieve information about a property. and the same property? it may be attached to multiple objects β€” see "Modeset Base Object Abstraction" for that whole situation πŸ¦‹

here's the spicy bit: the meaning of the values_ptr field changes depending on the property type. yep, it's giving shapeshifter. see drm_property.flags for more details on that πŸ’«

the enum_blob_ptr and count_enum_blobs fields are only meaningful when the property has the type DRM_MODE_PROP_ENUM or DRM_MODE_PROP_BITMASK. and for backwards compatibility, the kernel will always set count_enum_blobs to zero when the property has the type DRM_MODE_PROP_BLOB. so if the property has a different type, user-space must ignore these two fields. not "should", must β€” we respect the contract πŸ™ˆ

user-space is expected to retrieve values and enums by doing this ioctl at least twice: first round to get the number of elements, second round to get the elements themselves. two trips, one vibe check ✌️

πŸ’– round one: getting the count

to retrieve the number of elements, set count_values and count_enum_blobs to zero, then call the ioctl. count_values will be updated with the number of elements. and if the property has the type DRM_MODE_PROP_ENUM or DRM_MODE_PROP_BITMASK, count_enum_blobs gets updated too. slay, now you know the size πŸŽ€

πŸ’– round two: getting the goods

to retrieve the elements themselves, allocate an array for values_ptr and set count_values to its capacity. if the property has the type DRM_MODE_PROP_ENUM or DRM_MODE_PROP_BITMASK, allocate an array for enum_blob_ptr and set count_enum_blobs to its capacity. calling the ioctl again will fill the arrays. that's the whole trick, iykyk 🌟

ngl bestie, don't skip the first pass β€” you genuinely need the counts before you can allocate, and guessing sizes is not the move πŸ’€

πŸ‘‘ SEE ALSO πŸ‘‘

the whole friend group, fr fr 🫢


and that's the page, bestie!! πŸ’œ this icon lives in ./include/uapi/drm, dated October 2026 β€” go forth and GETPROPERTY responsibly, mwah πŸ˜˜πŸŽ€

πŸ“¦ where this page comes from