STRUCT DRM_CONNECTOR_FUNCS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… NAME πŸ’…

okay so bestie, you're in the Kernel API Manual and today's main character is struct drm_connector_funcs β€” it's literally for control connectors on a given device, and the way that's such a whole vibe πŸ˜­πŸ’– no cap, this struct is the plug for connector behavior, and we're gonna treat every field like the icon it is ✨


✨ SYNOPSIS ✨

here's the full roster of function pointers, bestie β€” every single one, exactly as the manual serves it, no edits, no skips, no β€œoops I forgot one” energy πŸ™ˆπŸ’…

       struct drm_connector_funcs {
           int (*dpms)(struct drm_connector *connector, int mode);
           void (*reset)(struct drm_connector *connector);
           enum drm_connector_status (*detect)(struct drm_connector *connector,
       bool force);
           void (*force)(struct drm_connector *connector);
           int (*fill_modes)(struct drm_connector *connector, uint32_t
       max_width, uint32_t max_height);
           int (*set_property)(struct drm_connector *connector, struct
       drm_property *property, uint64_t val);
           int (*late_register)(struct drm_connector *connector);
           void (*early_unregister)(struct drm_connector *connector);
           void (*destroy)(struct drm_connector *connector);
           struct drm_connector_state *(*atomic_create_state)(struct
       drm_connector *connector);
           struct drm_connector_state *(*atomic_duplicate_state)(struct
       drm_connector *connector);
           void (*atomic_destroy_state)(struct drm_connector *connector, struct
       drm_connector_state *state);
           int (*atomic_set_property)(struct drm_connector *connector, struct
       drm_connector_state *state, struct drm_property *property, uint64_t
       val);
           int (*atomic_get_property)(struct drm_connector *connector, const
       struct drm_connector_state *state, struct drm_property *property,
       uint64_t *val);
           void (*atomic_print_state)(struct drm_printer *p, const struct
       drm_connector_state *state);
           void (*oob_hotplug_event)(struct drm_connector *connector, enum
       drm_connector_status status);
           void (*debugfs_init)(struct drm_connector *connector, struct dentry
       *root);
           enum drm_connector_color_format (*color_format)( const struct
       drm_connector_state *conn_state);
        };

that's the whole synopsis for this part, and every field got its moment in the spotlight 🫢✨ part 1 of 3, and we are so not done yet πŸ’œ

πŸ’… Members πŸ’…

  • dpms β€” the legacy entry point for setting the per-connector DPMS state. Legacy DPMS is exposed as a standard property on the connector, but the DRM core diverts it to this callback. Heads up bestie: atomic drivers don't implement the 4 level DPMS support on the connector anymore β€” instead they only have an on/off "ACTIVE" property on the CRTC object.

This hook is not used by atomic drivers at all β€” the remapping of the legacy DPMS property is entirely handled in the DRM core.

RETURNS:

0 on success or a negative error code on failure.

  • reset β€” reset connector hardware and software state to off. The core doesn't call this directly β€” it only ever happens through drm_mode_config_reset. And no, it's not a helper hook, it's just like that for historical reasons πŸ’€

Atomic drivers can use drm_atomic_helper_connector_reset to reset atomic state using this hook.

  • detect β€” check to see if anything is attached to the connector. The force parameter is set to false whilst polling, and true when checking the connector due to a user request. force can be used by the driver to avoid expensive, destructive operations during automated probing. πŸ™ˆ

This callback is optional β€” if it's not implemented, the connector is considered as always being attached.

FIXME:

Note that this hook is only called by the probe helper. It's not in the helper library vtable purely for historical reasons. The only DRM core entry point to probe connector state is fill_modes.

Also note that the helper library will already hold drm_mode_config.connection_mutex. Drivers that need to grab additional locks to avoid races with concurrent modeset changes need to use drm_connector_helper_funcs.detect_ctx instead.

And one more: this callback can be called no matter what state the connector is in. Drivers that need the underlying device to be powered just to perform the detection will first need to make sure it's been properly enabled. ⚑

RETURNS:

drm_connector_status indicating the connector's status.

  • force β€” this function is called to update internal encoder state when the connector is forced to a certain state by userspace, either through the sysfs interfaces or on the kernel cmdline. In that case the detect callback isn't called. 🫢

FIXME:

Note that this hook is only called by the probe helper. It's not in the helper library vtable purely for historical reasons. The only DRM core entry point to probe connector state is fill_modes.

  • fill_modes β€” the entry point for output detection and basic mode validation. The driver should reprobe the output if needed (e.g. when hotplug handling is unreliable), add all detected modes to drm_connector.modes and filter out any the device can't support in any configuration. It also needs to filter out any modes wider or higher than the parameters max_width and max_height indicate. πŸ“

The drivers must also prune any modes no longer valid from drm_connector.modes. Furthermore it must update drm_connector.status and drm_connector.edid. If no EDID has been received for this output, connector->edid must be NULL.

Drivers using the probe helpers should use drm_helper_probe_single_connector_modes to implement this function.

RETURNS:

The number of modes detected and filled into drm_connector.modes.

  • set_property β€” this is the legacy entry point to update a property attached to the connector. 🧚

This callback is optional if the driver does not support any legacy driver-private properties. For atomic drivers it is not used, because property handling is done entirely in the DRM core.

RETURNS:

0 on success or a negative error code on failure.

  • late_register β€” this optional hook can be used to register additional userspace interfaces attached to the connector β€” light backlight control, i2c, DP aux or similar interfaces. It's called late in the driver load sequence from drm_connector_register when registering all the core drm connector interfaces. Everything added from this callback should be unregistered in the early_unregister callback. πŸ”₯

This is called while holding drm_connector.mutex.

Returns:

0 on success, or a negative error code on failure.

  • early_unregister β€” this optional hook should be used to unregister the additional userspace interfaces attached to the connector from late_register. It's called from drm_connector_unregister, early in the driver unload sequence, to disable userspace access before data structures are torn down. πŸŽ€

This is called while holding drm_connector.mutex.

  • destroy β€” clean up connector resources. This is called at driver unload time through drm_mode_config_cleanup. It can also be called at runtime when a connector is being hot-unplugged, for drivers that support connector hotplugging (e.g. DisplayPort MST). πŸ’€
  • atomic_create_state β€” allocate a pristine, initialized, state for the connector object and return it. This callback must have no side effects: in particular, the returned state must not be assigned to the object's state pointer and it must not affect the hardware state. ✨

RETURNS:

A new, pristine, connector state instance or an error pointer on failure.

  • atomic_duplicate_state β€” duplicate the current atomic state for this connector and return it. The core and helpers guarantee that any atomic state duplicated with this hook and still owned by the caller (i.e. not transferred to the driver by calling drm_mode_config_funcs.atomic_commit) will be cleaned up by calling the atomic_destroy_state hook in this structure. πŸ‘‘

This callback is mandatory for atomic drivers.

Atomic drivers which don't subclass struct drm_connector_state should use drm_atomic_helper_connector_duplicate_state. Drivers that subclass the state structure to extend it with driver-private state should use __drm_atomic_helper_connector_duplicate_state to make sure shared state is duplicated in a consistent fashion across drivers.

It is an error to call this hook before drm_connector.state has been initialized correctly.

NOTE:

If the duplicate state references refcounted resources, this hook must acquire a reference for each of them. The driver must release these references again in atomic_destroy_state.

RETURNS:

Duplicated atomic state or NULL when the allocation failed.

  • atomic_destroy_state β€” destroy a state duplicated with atomic_duplicate_state and release or unreference all resources it references. πŸ¦‹

This callback is mandatory for atomic drivers.

  • atomic_set_property β€” decode a driver-private property value and store the decoded value into the passed-in state structure. Since the atomic core decodes all standardized properties (even for extensions beyond the core set of properties which might not be implemented by all drivers), this requires drivers to subclass the state structure.

Such driver-private properties should really only be implemented for truly hardware/vendor specific state. Instead it's preferred to standardize atomic extension and decode the properties used to expose such an extension in the core. πŸ’œ

Do not call this function directly β€” use drm_atomic_connector_set_property instead.

This callback is optional if the driver does not support any driver-private atomic properties.

NOTE:

This function is called in the state assembly phase of atomic modesets, which can be aborted for any reason (including on userspace's request to just check whether a configuration would be possible). Drivers MUST NOT touch any persistent state (hardware or software) or data structures except the passed in state parameter. 🚨

Also, since userspace controls in which order properties are set, this function must not do any input validation (since the state update is incomplete and hence likely inconsistent). Instead, any such input validation must be done in the various atomic_check callbacks.

RETURNS:

0 if the property has been found, -EINVAL if the property isn't implemented by the driver (which shouldn't ever happen β€” the core only asks for properties attached to this connector). No other validation is allowed by the driver. The core already checks that the property value is within the range (integer, valid enum value, ...) the driver set when registering the property.

  • atomic_get_property β€” reads out the decoded driver-private property. This is used to implement the GETCONNECTOR IOCTL. πŸ”

Do not call this function directly β€” use drm_atomic_connector_get_property instead.

This callback is optional if the driver does not support any driver-private atomic properties.

RETURNS:

0 on success, -EINVAL if the property isn't implemented by the driver (which shouldn't ever happen β€” the core only asks for properties attached to this connector).

  • atomic_print_state β€” if the driver subclasses struct drm_connector_state, it should implement this optional hook for printing additional driver specific state. πŸ–¨οΈ

Do not call this directly β€” use drm_atomic_connector_print_state instead.

  • oob_hotplug_event β€” this will get called when a hotplug-event for a drm-connector has been received from a source outside the display driver / device. 🌈
  • debugfs_init β€” allows connectors to create connector-specific debugfs files. πŸ›
  • color_format β€” allows connectors to return a connector color format other than conn_state.color_format, for purposes of e.g. display protocol specific helper logic having already mapped it to an output format. 🎨

✨ Description ✨

Each CRTC may have one or more connectors attached to it. The functions below allow the core DRM code to control connectors, enumerate available modes, etc. Literally the whole vibe of this struct, no cap. πŸ’–

🌈 SEE ALSO ✨

okay bestie, this is the part where the manpage is like "here's everyone else at the function"β€”it's giving a whole group chat of related kernel docs, and you know we're gonna stan every single one πŸ’… so let's go, no skips:

  • the header they all live in: Kernel file ./include/drm/drm_connector.h πŸŽ€
  • enum drm_connector_status(9) β€” the vibe check enum for connector status ✨
  • enum drm_connector_registration_state(9) β€” registration state enum, lowkey important πŸ¦‹
  • enum drm_connector_tv_mode(9) β€” TV mode enum, yes ma'am πŸ“Ί
  • struct drm_scrambling(9) β€” scrambling struct, it's giving encrypted energy πŸ”
  • struct drm_hdmi_dsc_cap(9) β€” HDMI DSC capability struct πŸ’«
  • struct drm_hdmi_info(9) β€” the HDMI info struct, main character of the port world πŸ‘‘
  • enum drm_link_status(9) β€” link status enum, keep an eye on it 🌸
  • enum drm_panel_orientation(9) β€” panel orientation enum, rotate slay πŸ’…
  • enum drm_hdmi_broadcast_rgb(9) β€” HDMI broadcast RGB enum 🌈
  • struct drm_monitor_range_info(9) β€” monitor range info struct πŸ“
  • struct drm_luminance_range_info(9) β€” luminance range info struct, literally glowing ✨
  • enum drm_privacy_screen_status(9) β€” privacy screen status enum, no peeking πŸ™ˆ
  • enum drm_colorspace(9) β€” colorspace enum, rainbow moment 🌈
  • enum drm_output_color_format(9) β€” output color format enum 🎨
  • enum drm_connector_color_format(9) β€” connector color format enum πŸ–οΈ
  • enum drm_bus_flags(9) β€” bus flags enum, flags are iconic 🚩
  • struct drm_amd_vsdb_info(9) β€” AMD VSDB info struct, AMD girlies rise 🫢
  • struct drm_display_info(9) β€” display info struct, the whole aesthetic πŸ–ΌοΈ
  • struct drm_connector_tv_margins(9) β€” TV margins struct, boundaries bestie πŸŽ€
  • struct drm_tv_connector_state(9) β€” TV connector state struct πŸ“Ί
  • struct drm_connector_hdmi_infoframe(9) β€” HDMI infoframe struct, info but make it fancy πŸ’…
  • struct drm_connector_state(9) β€” connector state struct, the moment 🫢
  • struct drm_connector_cec_funcs(9) β€” CEC funcs struct πŸ”Œ
  • struct drm_connector_infoframe_funcs(9) β€” infoframe funcs struct ✨
  • struct drm_connector_hdmi_funcs(9) β€” HDMI funcs struct, sibling energy πŸ’œ
  • struct drm_cmdline_mode(9) β€” command line mode struct, old school cool πŸ’«
  • struct drm_connector_hdmi_audio(9) β€” HDMI audio struct, sound ON πŸ”Š
  • struct drm_connector_cec(9) β€” CEC struct πŸŽ›οΈ
  • struct drm_connector(9) β€” the connector struct itself, the blueprint, the icon πŸ‘‘
  • drm_connector_lookup(9) β€” go find your connector πŸ”
  • drm_connector_get(9) β€” grab a reference, hold it tight 🫢
  • drm_connector_put(9) β€” release it, let it go πŸ¦‹
  • drm_connector_is_unregistered(9) β€” is it unregistered? ask the function πŸ’€
  • struct drm_tile_group(9) β€” tile group struct 🧩
  • struct drm_connector_list_iter(9) β€” connector list iterator, loop era πŸ”
  • drm_for_each_connector_iter(9) β€” the macro that walks every connector, ate πŸ’…
  • drm_connector_for_each_possible_encoder(9) β€” and this one walks every possible encoder, periodt πŸ”₯

and that's the whole page bestie, we did it πŸŽ‰ no cap, every single reference made it out alive. this lil gem lives in ./include/drm, it's the struct drm_connector_funcs(9) page, and it's stamped October 2026 β€” so go forth, register your connectors, and remember: the vibe check is forever πŸ’–βœ¨πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from