Your message dated Sun, 16 Aug 2026 15:10:50 +0200
with message-id
<s24gp2msctccz2hierfy4anf2h72vneu7hdktl2cqbzezmvsua@4a2ajdgkfpje>
and subject line Re: Bug#1144500: linux-image-6.12.101+deb13-amd64: second
monitor goes into standby during early boot
has caused the Debian Bug report #1144500,
regarding linux-image-6.12.101+deb13-amd64: second monitor goes into standby
during early boot
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1144500: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1144500
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: linux-image-6.12.101+deb13-amd64 Version: 6.12.101-1 Severity:
normal
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
--- End Message ---
--- Begin Message ---
On Sun, Aug 16, 2026 at 08:24:47AM +0000, Manfred wrote:
> Package: linux-image-6.12.101+deb13-amd64
> Version: 6.12.101-1 (adjust to actual version if different)
This bug report looks really like LLM generation. Since nothing in it
can be taken for granted, we will just close it here and now and not
further look at it.
For the future, please use reportbug. This will also try to collect all
the information we would like see initially.
Bastian
--
What kind of love is that? Not to be loved; never to have shown love.
-- Commissioner Nancy Hedford, "Metamorphosis",
stardate 3219.8
--- End Message ---
