Same bug here, and I believe I can add the root cause plus an upstream fix that Ubuntu's kernel is missing. It is not a 26.04 regression: I measured identical behaviour on 24.04 (kernel 7.0.0-30, mutter 46.2) on 1 Sep 2026, and it persists on 26.04 (7.0.0-38-generic, mutter 50.1).
Hardware: ThinkPad E14 Gen 6 (21M7), Intel Meteor Lake-P [Arc] 8086:7d55, i915, native HDMI port. Sink: LG HDR 4K at [email protected], port_clock 533250 kHz, i.e. above 340 MHz, so HDMI 2.0 SCDC scrambling with the 1/40 TMDS bit-clock ratio is required. What happens, from drm.debug=0x06 plus reading the sink's SCDC registers over DDC (i2cget on the gmbus, address 0x54): 1. Any full modeset on the HDMI pipe (unlock after blanking, resume from s2idle, or one forced from userspace) completes without errors: intel_hdmi_handle_sink_scrambling: scrambling=yes, TMDS bit clock ratio=1/40 2. Within milliseconds the sink drops HPD for about 2 s and raises it again (same as the original report). 3. Nothing re-runs the modeset. The connector stays connected/enabled/DPMS On, EDID and audio ELD are valid, and the screen shows "No Signal". Sink SCDC state, working vs failing (same monitor, cable and mode): 0x20 TMDS_Config 0x03 / 0x03 <- the source's SCDC write always lands 0x21 Scrambler_Status 0x01 / 0x00 0x40 Status_Flags_0 0x0f / 0x00 <- no TMDS clock detected at all The SCDC character-error counters (0x50-0x55) read zero on a healthy link, so the cable is not the cause. Reliable workaround: switch to a VT and back (Ctrl+Alt+F3, then F2). That forces a second modeset after the HPD bounce has settled. Replugging the cable or toggling the display in Settings works only intermittently. Running at 4K@30 (below 340 MHz, no scrambling) prevents it: after switching to 4K@30, the next lock/blank/unlock cycle woke the monitor normally. Upstream fix: drm/xe issue #6868 (same symptom on Alder Lake-N with a 4K60 HDMI 2.0 sink) led to "drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status", merged in drm/i915/kernel commit b7d51d65 on 2026-06-11. That patch implements the HDMI 2.0 spec requirement to poll Scrambler_Status for up to 200 ms after scrambled transmission starts. i915.ko in 7.0.0-38-generic does not contain it: there is no poll and no "Timed out waiting for scrambling enable" string. Request: please backport b7d51d65 to the resolute 7.0 kernel. I couldn't add a linux task to this bug myself ("Not allowed here") — could someone with bug-control rights add it, since the fix is in i915 rather than mutter? https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6868 ** Bug watch added: gitlab.freedesktop.org/drm/xe/kernel/-/issues #6868 https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6868 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2169932 Title: [i915] External HDMI monitor gets no signal after lock/unlock on 26.04 (regression from24.04) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2169932/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
