fix(drm-extras): re-emit Connected event when modes change on already-connected connector

[coleleavitt]

Fixes #1922

Problem

ConnectorScanner treats (Connected, Connected) as a no-op, only tracking state transitions. When a connector's mode list changes while remaining Connected (e.g., EDID becomes available after initial probe returned empty modes), no event is emitted.

This causes USB-C dock monitors with DP MST/alt-mode to get stuck in a permanent "connected but never activated" state when the kernel reports the connector as Connected before EDID data is ready.

Fix

Add a new Changed event variant to both ConnectorScanEvent and DrmScanEvent. When a connector stays Connected but its mode list differs from the previous scan, emit Changed instead of silently ignoring it:

// ConnectorScanEvent
pub enum ConnectorScanEvent {
    Connected(connector::Info),
    Disconnected(connector::Info),
    Changed(connector::Info),  // NEW: mode list changed while staying connected
}

// DrmScanEvent
pub enum DrmScanEvent {
    Connected { connector, crtc },
    Disconnected { connector, crtc },
    Changed { connector, crtc },  // NEW
}

The scanner logic:

(State::Connected, State::Connected) => {
    if old.modes() != conn.modes() {
        changed.push(conn);
    }
}

This is better than re-emitting Connected (original approach) because:

• Compositors get explicit control over how to handle mode-list updates vs initial connections
• No duplicate Connected semantics
• Covers Smithay doesn't play nice when EDID drops due to video switchbox changing inputs #1859 (video switchbox) naturally — input change = mode list change on an already-connected connector

Context

Discovered while debugging intermittent monitor activation failures on a ThinkPad P16 Gen 3 with USB-C Dock Gen 2 (DP alt-mode + MST). Verified against kernel DRM source (drm_probe_helper.c lines 598-653) — drm_helper_probe_detect() sets connector status before EDID/mode enumeration, so userspace can observe Connected with empty modes.

Related:

• Smithay Smithay doesn't play nice when EDID drops due to video switchbox changing inputs #1859 — same root cause with video switchbox
• niri xwm: replace LATE_SURFACE_ID #869, #2691 — downstream symptoms
• niri PR #3409 — compositor-level workaround (bounded rescan timer)

[PolyMeilex]

Hi!

1. Have you debugged this to check if what LLM states about lazy mode loading aligns with reality?
2. If so, wouldn't it be better to not emit the first connected event (the one that is not yet ready), rather than send duplicated connected event?
3. Or if it turns out that the modes can change at any time and not only on startup, perhaps we need a new Changed/Updated event?

[coleleavitt]

Hi! Thanks for the thoughtful review.

1. Verification:

The initial investigation was LLM-assisted, but I've verified the mechanism against kernel DRM source and have a hardware reproducer (ThinkPad P16 Gen 3 + USB-C Dock Gen 2, DP alt-mode + MST hub).

The relevant kernel codepath is drm_helper_probe_single_connector_modes() in drm_probe_helper.c:

• Lines 598-606: drm_helper_probe_detect() sets connector->status to connected before EDID/mode enumeration
• Line 649: drm_helper_probe_get_modes() reads EDID after status — can return 0 for DP MST when link training is still in-progress
• Lines 651-653: Kernel falls back to drm_add_modes_noedid(1024x768) when count == 0 && connected

So what smithay sees via DRM_IOCTL_MODE_GETCONNECTOR: connector reports Connected with either zero modes or just the 1024x768 fallback. A subsequent probe (triggered by kernel hotplug event as EDID arrives) returns the real mode list. With the current (Connected, Connected) => {} arm, that second probe is silently ignored.

On my hardware, this manifests as intermittent monitor activation failure — niri's pick_mode() returns None on the first probe, logs warn!("error connecting connector: no mode"), and never retries because smithay never re-emits the event.

2. Suppressing the first empty-modes Connected:

I considered this, but modes().is_empty() on a Connected connector isn't a reliable "not ready yet" signal:

• The kernel already provides 1024x768 fallbacks for no-EDID connectors (lines 651-653 above), so modes() may not actually be empty — just wrong
• Suppressing would break legitimate no-EDID connectors (VGA without EDID, some KVM switches)
• It would also break the switchbox case from Smithay doesn't play nice when EDID drops due to video switchbox changing inputs #1859, where suppressing the initial Connected means the output never activates at all

3. New Changed event — I think this is the right approach.

The current PR overloads Connected for something semantically different. A new variant like ConnectorScanEvent::Changed(connector::Info) would:

• Give compositors explicit control over how to handle mode-list updates vs initial connections
• Cover Smithay doesn't play nice when EDID drops due to video switchbox changing inputs #1859 naturally (switchbox input change = mode list change on an already-connected connector)
• Avoid the duplicate Connected semantics concern you raised

Happy to revise the PR with a Changed variant. Should it fire on any connector::Info change (property changes, encoder reassignment, etc.), or specifically just mode-list changes?

[coleleavitt]

@PolyMeilex

[PolyMeilex]

Seems good now