STRUCT DRM_PROPERTY(9)

💖 NAME 💖

struct drm_property — the modeset object property. that's it, that's the vibe 🎀

(this one lives in the Kernel API Manual, bestie — yes, that manual 😌)

---

✨ SYNOPSIS ✨

okay so here's literally the whole struct, copy-paste exact, no cap:

struct drm_property {
    struct list_head head;
    struct drm_mode_object base;
    uint32_t flags;
    char name[DRM_PROP_NAME_LEN];
    uint32_t num_values;
    uint64_t *values;
    struct drm_device *dev;
    struct list_head enum_list;
 };

---

🫶 Members 🫶

• head — per-device list of properties, for cleanup. the little group chat roster of every property on this device 💅
• base — base KMS object. the foundation, the main character energy 🌟
• flags — property flags AND type. a property has to be one of the following types, so pick a lane:

🌈 the types (flags, but make it a personality quiz) 🌈

• DRM_MODE_PROP_RANGE — range properties report their minimum and maximum admissible unsigned values. the KMS core verifies that values set by application fit in that range. the range is unsigned. range properties are created using drm_property_create_range ✨
• DRM_MODE_PROP_SIGNED_RANGE — range properties report their minimum and maximum admissible unsigned values. (yes, the page says unsigned here too, and then immediately says the range is signed 🙈 that's just what it says, i'm not fixing it.) the KMS core verifies that values set by application fit in that range. the range is signed. range properties are created using drm_property_create_signed_range.
• DRM_MODE_PROP_ENUM — enumerated properties take a numerical value that ranges from 0 to the number of enumerated values defined by the property minus one, and associate a free-formed string name to each value. applications can retrieve the list of defined value-name pairs and use the numerical value to get and set property instance values. enum properties are created using drm_property_create_enum. it's giving dropdown menu 🎀
• DRM_MODE_PROP_BITMASK — bitmask properties are enumeration properties that additionally restrict all enumerated values to the 0..63 range. bitmask property instance values combine one or more of the enumerated bits defined by the property. bitmask properties are created using drm_property_create_bitmask. sixty-four little boxes, slay 🔥
• DRM_MODE_PROP_OBJECT — object properties are used to link modeset objects. this is used extensively in the atomic support to create the display pipeline, by linking drm_framebuffer to drm_plane, drm_plane to drm_crtc and drm_connector to drm_crtc. an object property can only link to a specific type of drm_mode_object, this limit is enforced by the core. object properties are created using drm_property_create_object.

object properties work like blob properties, but in a more general fashion. they are limited to atomic drivers and must have the DRM_MODE_PROP_ATOMIC flag set. ⚠️

• DRM_MODE_PROP_BLOB — blob properties store a binary blob without any format restriction. the binary blobs are created as KMS standalone objects, and blob property instance values store the ID of their associated blob object. blob properties are created by calling drm_property_create with DRM_MODE_PROP_BLOB as the type.

actual blob objects to contain blob data are created using drm_property_create_blob, or through the corresponding IOCTL.

besides the built-in limit to only accept blob objects, blob properties work exactly like object properties. the only reasons blob properties exist is backwards compatibility with existing userspace. honestly? legacy icon behavior, we respect it 💀

🦋 the extra flag combos 🦋

in addition, a property can have any combination of the below flags:

• DRM_MODE_PROP_ATOMIC — set for properties which encode atomic modeset state. such properties are not exposed to legacy userspace. lowercase-only club, sorry legacy users 🚫
• DRM_MODE_PROP_IMMUTABLE — set for properties whose values cannot be changed by userspace. the kernel is allowed to update the value of these properties. this is generally used to expose probe state to userspace, e.g. the EDID, or the connector path property on DP MST sinks. kernel can update the value of an immutable property by calling drm_object_property_set_value. read-only for you, not for kernel. classic 👑

🍓 and the rest of the members 🍓

• name — symbolic name of the properties
• num_values — size of the values array.
• values — array with limits and values for the property. the interpretation of these limits is dependent upon the type per flags.
• dev — DRM device 💜
• enum_list — list of drm_prop_enum_list structures with the symbolic names for enum and bitmask values.

---

🌸 Description 🌸

so this structure represents a modeset object property. it combines both the name of the property with the set of permissible values. which means: when a driver wants to use a property with the same name on different objects, but with different value ranges, then it must create a property for each one. the example they give is rotation of drm_plane, when e.g. the primary plane cannot be rotated. but if both the name and the value range match, then the same property structure can be instantiated multiple times for the same object. userspace must be able to cope with this and cannot assume that the same symbolic property will have the same modeset object ID on all modeset objects. no cap, do not assume 😤

properties are created by one of the special functions, as explained in detail in the flags structure member.

to actually expose a property it must be attached to each object using drm_object_attach_property. currently properties can only be attached to drm_connector, drm_crtc and drm_plane. those three, periodt.

properties are also used as the generic metadata transport for the atomic IOCTL. everything that was set directly in structures in the legacy modeset IOCTLs (like the plane source or destination windows, or e.g. the links to the CRTC) is exposed as a property with the DRM_MODE_PROP_ATOMIC flag set. glow-up of the century honestly ✨

fr fr bestie: this is the atomic pipelines' plumbing. if you get the flags wrong your whole display goes 🙈, so double-check which creation function you're reaching for.

---

👑 SEE ALSO 👑

kernel file ./include/drm/drm_property.h, struct drm_property_enum(9), struct drm_property_blob(9), drm_property_type_is(9), drm_property_find(9) 🦋

---

and that's the whole page, ilysm for reading all the way through 🫶 this one came from ./include/drm, dated October 2026, and yes it's filed under struct drm_property(9) — go be iconic with your properties 💅🎀