Subject: linux-image-6.12.101+deb13-amd64: second monitor goes into standby during early boot (before LUKS passphrase prompt) — works correctly with 6.12.48+deb13-amd64
Package: linux-image-6.12.101+deb13-amd64
Version: 6.12.101-1 (adjust to actual version if different)
Severity: normal
-- Summary --
With kernel 6.12.101+deb13-amd64, my second monitor (connected via
HDMI) goes into standby during early boot — specifically it is
already off by the time the LUKS passphrase prompt is shown. This
means the disk-decryption prompt is not visible on it.
With kernel 6.12.48+deb13-amd64 on the exact same hardware/setup,
both monitors stay on throughout the entire boot process, including
the LUKS prompt, with no configuration changes needed.
Booting the older 6.12.48+deb13-amd64 kernel is currently my only
reliable workaround (aside from setting the monitor to "Auto Source
Switching" in its own OSD menu, which appears to keep it actively
scanning for signal and thus prevents the standby timeout from
completing).
-- Hardware --
GPU: Intel Corporation IvyBridge GT2 [HD Graphics 4000] (rev 09)
(i915 driver)
lspci: 00:02.0 VGA compatible controller
Monitors: 2x Samsung, one is a Samsung S27R65 (EDID: Mfg SAM,
Model S27R65, Product code 4165 / 0x1045, manufactured
2020 week 50), connected via HDMI (DRM connector
card0-HDMI-A-1 per ddcutil).
-- Steps to reproduce --
1. Boot the system with linux-image-6.12.101+deb13-amd64.
2. Observe: by the time the LUKS passphrase prompt appears, the
second (HDMI) monitor has already switched to standby.
3. Reboot with linux-image-6.12.48+deb13-amd64.
4. Observe: both monitors stay on/active throughout boot, including
the LUKS prompt, with identical hardware and cabling.
-- What I've already tried/ruled out --
- ddcutil confirms DDC/CI communication works with the monitor in
principle (getvcp d6 returns "Power mode: DPM: On, DPMS: Off").
- ddcutil capabilities fails ("Maximum DDC retries exceeded"), so no
vendor-specific power-timer VCP code could be identified/adjusted.
- A systemd oneshot service running "ddcutil setvcp d6 01" after
display-manager.service does NOT recover the monitor — the standby
appears to happen too early (before/during LUKS decryption in
initramfs), and a DDC power-mode write alone does not force the
panel to re-scan for signal once it has already timed out.
- Setting the monitor's own OSD to auto-detect/auto-switch input
works around the issue by keeping it in an active scanning state,
which suggests the timing/duration of the "no signal" period
during early KMS/i915 initialization changed between 6.12.48 and
6.12.101.
-- Request --
Could someone identify which i915-related commit(s) were backported
into the 6.12.y stable series between 6.12.48 and 6.12.101 that could
affect early KMS modesetting / connector detect / DP-HDMI output
timing? I'm happy to test patches, provide dmesg diffs between the
two kernel versions, or do further bisecting if that would help.
I can attach:
- journalctl -k output filtered for i915/drm/dp/connector/dpms from
both kernel boots, diffed
- Full dmesg from both kernels if needed
