STRUCT DRM_CONNECTOR(9)
π struct drm_connector(9) β part 1 of 3, bestie π
okay so before we even get into it β hi, welcome to the Kernel API Manual, this is struct drm_connector(9), and this page is long, so we're splitting it into three parts. This is part one. Buckle in. π
β¨ NAME β¨
struct drm_connector β the central DRM connector control structure, no cap. Like, this is THE struct. The main character of the connector world. π
π¦ SYNOPSIS π¦
here's the full struct, and yes bestie you're gonna want to read every field because i'm not skipping a single one, i would never do that to you:
struct drm_connector {
struct drm_device *dev;
struct device *kdev;
struct device_attribute *attr;
struct fwnode_handle *fwnode;
struct list_head head;
struct list_head global_connector_list_entry;
struct drm_mode_object base;
char *name;
struct mutex mutex;
unsigned index;
int connector_type;
int connector_type_id;
bool interlace_allowed;
bool doublescan_allowed;
bool stereo_allowed;
bool ycbcr_420_allowed;
enum drm_connector_registration_state registration_state;
struct list_head modes;
enum drm_connector_status status;
struct list_head probed_modes;
struct drm_display_info display_info;
const struct drm_connector_funcs *funcs;
struct drm_property_blob *edid_blob_ptr;
struct drm_object_properties properties;
struct drm_property *scaling_mode_property;
struct drm_property *vrr_capable_property;
struct drm_property *colorspace_property;
struct drm_property *color_format_property;
struct drm_property_blob *path_blob_ptr;
unsigned int max_bpc;
struct drm_property *max_bpc_property;
struct drm_privacy_screen *privacy_screen;
struct notifier_block privacy_screen_notifier;
struct drm_property *privacy_screen_sw_state_property;
struct drm_property *privacy_screen_hw_state_property;
struct drm_property *broadcast_rgb_property;
#define DRM_CONNECTOR_POLL_HPD (1 << 0);
#define DRM_CONNECTOR_POLL_CONNECT (1 << 1);
#define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2);
uint8_t polled;
int dpms;
const struct drm_connector_helper_funcs *helper_private;
struct drm_cmdline_mode cmdline_mode;
enum drm_connector_force force;
const struct drm_edid *edid_override;
struct mutex edid_override_mutex;
u64 epoch_counter;
u32 possible_encoders;
struct drm_encoder *encoder;
#define MAX_ELD_BYTES 128;
uint8_t eld[MAX_ELD_BYTES];
struct mutex eld_mutex;
bool latency_present[2];
int video_latency[2];
int audio_latency[2];
struct i2c_adapter *ddc;
int null_edid_counter;
unsigned bad_edid_counter;
bool edid_corrupt;
u8 real_edid_checksum;
struct dentry *debugfs_entry;
struct drm_connector_state *state;
struct drm_property_blob *tile_blob_ptr;
bool has_tile;
struct drm_tile_group *tile_group;
bool tile_is_single_monitor;
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
struct llist_node free_node;
struct drm_connector_hdmi hdmi;
struct drm_connector_hdmi_audio hdmi_audio;
struct drm_connector_cec cec;
};
ok real talk β those #define lines are chillin' inside the struct body in this layout, semicolons and all. that's exactly how it's written here, so that's exactly how i'm giving it to you. copy it as-is, do not "fix" it, i'm begging π
and yes, there's genuinely a #define MAX_ELD_BYTES 128; in there too β 128 bytes of ELD, iconic. β
that's the whole shape of it for now β the fields themselves get their whole own moment coming up, so stay tuned for part 2, we are not done here π«ΆπΈ
β¨ MEMBERS β¨
okay bestie, this is the full roster of struct members, and we are not skipping a single one π
every field, every lock, every NULL, we're getting through all of it together π«Ά
devβ the parent DRM device πkdevβ the kernel device used for sysfs attributesattrβ sysfs attributesfwnodeβ the associated fwnode supplied by platform firmware πΈ. Drivers can set this to associate a fwnode with a connector, and drivers are expected to get a reference on the fwnode when setting this.drm_connector_cleanupwill callfwnode_handle_puton this.headβ the list of all connectors on adev, linked fromdrm_mode_config.connector_list. It's protected bydrm_mode_config.connector_list_lock, but likeβ¦ please only usedrm_connector_list_iterto walk this list, ok? πglobal_connector_list_entryβ the connector's entry in the global connector-list, used bydrm_connector_find_by_fwnode.baseβ base KMS objectnameβ the human readable name, and yes it can be overwritten by the driver β¨mutexβ lock for general connector state, but currently it only protectsregistered. Most of the connector state is still protected bydrm_mode_config.mutex. iykyk π«indexβ the compacted connector index, which matches the position inside themode_config.listfor drivers not supporting hot-add/removing. Can be used as an array index. It is invariant over the lifetime of the connector β lowkey iconic of it πconnector_typeβ one of theDRM_MODE_CONNECTOR_<foo>types fromdrm_mode.hconnector_type_idβ index into the connector type enuminterlace_allowedβ can this connector handle interlaced modes? Only used bydrm_helper_probe_single_connector_modesfor mode filtering.doublescan_allowedβ can this connector handle doublescan? Only used bydrm_helper_probe_single_connector_modesfor mode filtering.stereo_allowedβ can this connector handle stereo modes? Only used bydrm_helper_probe_single_connector_modesfor mode filtering.ycbcr_420_allowedβ this bool says whether the connector is capable of handling YCBCR 420 output. While parsing the EDID blocks it's very helpful to know if the source is capable of handling YCBCR 420 outputs πregistration_stateβ is this connector initializing, exposed (registered) with userspace, or unregistered? Protected bymutex.modesβ the modes available on this connector (fromfill_modes+ user). Protected bydrm_mode_config.mutex.statusβ one of thedrm_connector_statusenums (connected, not, or unknown). Protected bydrm_mode_config.mutex.probed_modesβ these are the modes added by probing with DDC or the BIOS, before filtering is applied. Used by the probe helpers. Protected bydrm_mode_config.mutex.display_infoβ display information gets filled from EDID information when a display is detected. For non hot-pluggable displays such as flat panels in embedded systems, the driver should initialize thedrm_display_info.width_mmanddrm_display_info.height_mmfields with the physical size of the display. Protected bydrm_mode_config.mutex.funcsβ connector control functionsedid_blob_ptrβ the DRM property containing EDID if present. Protected bydrm_mode_config.mutex.
π¨ This must be updated only by callingdrm_edid_connector_updateordrm_connector_update_edid_property. And This must not be used by drivers directly. no cap, hands off π₯
propertiesβ property tracking for this connectorscaling_mode_propertyβ optional atomic property to control the upscaling. Seedrm_connector_attach_content_protection_property.vrr_capable_propertyβ optional property to help userspace query hardware support for variable refresh rate on a connector π Drivers can add the property to a connector by callingdrm_connector_attach_vrr_capable_property.
This should be updated only by calling drm_connector_set_vrr_capable_property.
colorspace_propertyβ connector property to set the suitable colorspace supported by the sink πcolor_format_propertyβ connector property to set the suitable color format supported by the sinkpath_blob_ptrβ DRM blob property data for the DP MST path property. This should only be updated by callingdrm_connector_set_path_property.max_bpcβ the maximum bits per color channel the connector supports.max_bpc_propertyβ default connector property for the max bpc to be driven out of the connector.privacy_screenβ thedrm_privacy_screenfor this connector, orNULL.privacy_screen_notifierβ the privacy-screennotifier_blockprivacy_screen_sw_state_propertyβ optional atomic property for the connector to control the integrated privacy screen πprivacy_screen_hw_state_propertyβ optional atomic property for the connector to report the actual integrated privacy screen state.broadcast_rgb_propertyβ connector property to set the Broadcast RGB selection to output with.polledβ the connector polling mode, a combination of:DRM_CONNECTOR_POLL_HPDβ the connector generates hotplug events and doesn't need to be periodically polled. The CONNECT and DISCONNECT flags must not be set together with the HPD flag π«DRM_CONNECTOR_POLL_CONNECTβ periodically poll the connector for connection.DRM_CONNECTOR_POLL_DISCONNECTβ periodically poll the connector for disconnection, without causing flickering even when the connector is in use. DACs should rarely do this without a lot of testing. fr fr, test it π
Set to 0 for connectors that don't support connection status discovery.
dpmsβ the current dpms state. For legacy drivers thedrm_connector_funcs.dpmscallback must update this. For atomic drivers, this is handled by the core atomic code, and drivers must only takedrm_crtc_state.activeinto account πhelper_privateβ mid-layer private datacmdline_modeβ the mode line parsed from the kernel cmdline for this connectorforceβ aDRM_FORCE_<foo>state for forced mode setsedid_overrideβ the override EDID set via debugfs.
β οΈ Do not modify or access outside of the drm_edid_override_* family of functions. seriously, that's the whole rule π«Ά
edid_override_mutexβ protects access toedid_override.epoch_counterβ used to detect changes in the connector. It gets increased when the connector, including its status, is changed β±οΈpossible_encodersβ bit mask of encoders that can drive this connector.drm_encoder_indexdetermines the index into the bitfield and the bits are set withdrm_connector_attach_encoder.encoderβ the currently bound encoder driving this connector, if any. Only really meaningful for non-atomic drivers. Atomic drivers should instead look atdrm_connector_state.best_encoder, and in case they need the CRTC driving this output,drm_connector_state.crtcπeldβ EDID-like data, if present, protected byeld_mutexeld_mutexβ protection for concurrent access toeldlatency_presentβ AV delay info from ELD, if foundvideo_latencyβ video latency info from ELD, if found.[0]: progressive,[1]: interlacedaudio_latencyβ audio latency info from ELD, if found.[0]: progressive,[1]: interlacedddcβ the associated ddc adapter. A connector usually has its associated ddc adapter. If a driver uses this field, then an appropriate symbolic link is created in the connector sysfs directory to make it easy for the user to tell which i2c adapter is for a particular display π
The field should be set by calling drm_connector_init_with_ddc.
null_edid_counterβ tracks sinks that give us all zeros for the EDID. Needed to workaround some HW bugs where we get all0s πbad_edid_counterβ tracks sinks that give us an EDID with invalid checksumedid_corruptβ indicates whether the last read EDID was corrupt. Used in Displayport compliance testing - Displayport Link CTS Core 1.2 rev1.1 4.2.2.6real_edid_checksumβ the real edid checksum for a corrupted edid block. Required in Displayport 1.4 compliance testing rev1.1 4.2.2.6debugfs_entryβ debugfs directory for this connectorstateβ the current atomic state for this connector. This is protected bydrm_mode_config.connection_mutex. Note that nonblocking atomic commits access the current connector state without taking locks. Either by going through thestruct drm_atomic_commitpointers, seefor_each_oldnew_connector_in_state,for_each_old_connector_in_stateandfor_each_new_connector_in_state. Or through careful ordering of atomic commit operations as implemented in the atomic helpers, seestruct drm_crtc_commitπ§tile_blob_ptrβ DRM blob property data for the tile property (used mostly by DP MST). This is meant for screens which are driven through separate display pipelines represented bydrm_crtc, which might not be running with genlocked clocks. For tiled panels which are genlocked, like dual-link LVDS or dual-link DSI, the driver should try to not expose the tiling and virtualize bothdrm_crtcanddrm_planeif needed.
This should only be updated by calling drm_connector_set_tile_property.
has_tileβ is this connector connected to a tiled monitor?tile_groupβ tile group for the connected monitortile_is_single_monitorβ whether the tile is one monitor housingnum_h_tileβ number of horizontal tiles in the tile groupnum_v_tileβ number of vertical tiles in the tile grouptile_h_locβ horizontal location of this tiletile_v_locβ vertical location of this tiletile_h_sizeβ horizontal size of this tile.tile_v_sizeβ vertical size of this tile.free_nodeβ list used only bydrm_connector_list_iterto be able to clean up a connector from any context, in conjunction withdrm_mode_config.connector_free_work.hdmiβ HDMI-related variable and properties.hdmi_audioβ HDMI codec properties and non-DRM state.cecβ CEC-related data π
β¨ DESCRIPTION β¨
okay so picture this bestie: each connector may be connected to one or more CRTCs π«Ά β like, it's not locked into a single one, it can have several. or, plot twist, a connector may be clonable by another connector π β but only if they can share a CRTC. that's the whole rule, no cap. so the vibe check is: can they share? then yes, clone away π
and every connector also has a specific position in the broader display π β the docs call this a 'screen', lowercase, in quotes, because honestly it's giving main character but it could span multiple monitors π. so yeah, "screen" here is doing a lot of heavy lifting. it's not necessarily one monitor, bestie, it's the whole spread. iconic behaviour fr fr π
π SEE ALSO π
the kernel file to go look at is ./include/drm/drm_connector.h β that's your source of truth, go read it, i'll wait π§
and then, the extended universe. yes there are this many, and yes every single one of them matters π don't skip the "boring" ones (there are no boring ones, periodt):
enum drm_connector_status(9)β the status enum, essential πenum drm_connector_registration_state(9)β registration state, we love a stateenum drm_connector_tv_mode(9)β tv mode enum, yes that's a thingstruct drm_scrambling(9)β scrambling, and no we're not talking about eggs πstruct drm_hdmi_dsc_cap(9)β the hdmi dsc capability structstruct drm_hdmi_info(9)β hdmi info, straight upenum drm_link_status(9)β link status, check itenum drm_panel_orientation(9)β which way is the panel facingenum drm_hdmi_broadcast_rgb(9)β broadcast rgb, yupstruct drm_monitor_range_info(9)β monitor range infostruct drm_luminance_range_info(9)β luminance range info, the glow-up infoenum drm_privacy_screen_status(9)β privacy screen status, very demureenum drm_colorspace(9)β colorspace!! aesthetic!!enum drm_output_color_format(9)β output color format, slayenum drm_connector_color_format(9)β connector color format, adjacent slayenum drm_bus_flags(9)β bus flags, little flagsstruct drm_amd_vsdb_info(9)β amd vsdb info, niche and we respect itstruct drm_display_info(9)β the display info struct, big onestruct drm_connector_tv_margins(9)β tv margins, give it some space π«Άstruct drm_tv_connector_state(9)β tv connector statestruct drm_connector_hdmi_infoframe(9)β hdmi infoframe structstruct drm_connector_state(9)β connector state, the momentstruct drm_connector_cec_funcs(9)β cec funcsstruct drm_connector_infoframe_funcs(9)β infoframe funcsstruct drm_connector_hdmi_funcs(9)β hdmi funcsstruct drm_connector_funcs(9)β the connector funcs themselves πstruct drm_cmdline_mode(9)β cmdline mode, command line erastruct drm_connector_hdmi_audio(9)β hdmi audio struct, sound on πstruct drm_connector_cec(9)β cec structdrm_connector_lookup(9)β go find a connectordrm_connector_get(9)β grab a reference, don't be weird about itdrm_connector_put(9)β and put it back, balanced queen βοΈdrm_connector_is_unregistered(9)β is it unregistered? askstruct drm_tile_group(9)β tile group, tiled agendastruct drm_connector_list_iter(9)β the list iterator, looping icondrm_for_each_connector_iter(9)β the for-each macro, go iterate bestiedrm_connector_for_each_possible_encoder(9)β and iterate the possible encoders too, why not β¨
that's the whole page, bestie, you made it to the end π this was struct drm_connector(9) from the ./include/drm corner of the kernel, dated October 2026 β go forth and connect some connectors, you absolute icon ππ
π¦
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms