Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #93743 > unrolled thread

Bug#1144500: linux-image-6.12.101+deb13-amd64: second monitor goes into standby during early boot

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1144500: linux-image-6.12.101+deb13-amd64: second monitor goes into standby during early boot Manfred <Kontakt.onm@posteo.net> - 2026-08-16 10:30 +0200
    Bug#1144500: marked as done (linux-image-6.12.101+deb13-amd64:  second monitor goes into standby during early boot) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-08-16 15:20 +0200

#93743 — Bug#1144500: linux-image-6.12.101+deb13-amd64: second monitor goes into standby during early boot

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

[toc] | [next] | [standalone]

#93749 — Bug#1144500: marked as done (linux-image-6.12.101+deb13-amd64: second monitor goes into standby during early boot)

[Multipart message — attachments visible in raw view] — view raw

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 owner@bugs.debian.org
immediately.)


-- 
1144500: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1144500
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web