https://bugs.kde.org/show_bug.cgi?id=517290

--- Comment #3 from Andrija <[email protected]> ---
Here is a full account of my reproduction attempts and collected data:

---

**Reproduction attempt 1 — dbus screen blank command:**

I was able to reproduce the bug using the following command:

  sleep 0.5 && dbus-send --session --print-reply \
    --dest=org.kde.kglobalaccel /component/org_kde_powerdevil \
    org.kde.kglobalaccel.Component.invokeShortcut string:"Turn Off Screen"

After triggering screen blank this way, the external HDMI monitor would not
wake — same behavior as described in the original report.

I then physically disconnected and reconnected the HDMI cable, which restored
the monitor. After reconnection, the bug was NO LONGER reproducible — both
monitors woke correctly after blanking. The following journalctl log was
captured in this working state (for comparison):

  Mar 09 13:26:27 org_kde_powerdevil[611699]: (i2c_detect_x37) Extra x37 sleep:
Sleeping for 400 milliseconds
  Mar 09 13:26:28 org_kde_powerdevil[611699]: (i2c_detect_x37) Extra x37 sleep:
Sleeping for 400 milliseconds
  Mar 09 13:26:28 org_kde_powerdevil[611699]: (i2c_detect_x37) Extra x37 sleep:
Sleeping for 400 milliseconds
  Mar 09 13:26:29 org_kde_powerdevil[611699]: Watching for display connection
changes, resolved watch mode = Watch_Mode_Xevent, poll loop interval = 100
millisec
  Mar 09 13:26:29 org_kde_powerdevil[611699]: extra_stabilization_millisec: 0,
stabilization_poll_millisec: 100
  Mar 09 13:26:29 org_kde_powerdevil[611699]: libddcutil recheck thread
0x555fa18e4b50 started
  Mar 09 13:26:29 org_kde_powerdevil[611699]: libddcutil watch thread
0x555fa18859e0 started
  Mar 09 13:26:29 org_kde_powerdevil[611699]: Display redetection finished.
  Mar 09 13:26:29 org_kde_powerdevil[611699]: Unquiescing libddcutil API...
  Mar 09 13:26:29 org_kde_powerdevil[1304978]: (dw_recheck_displays_func)
Recheck interval: Sleeping for 200 milliseconds

This shows DDC initializing correctly in the working state — libddcutil watch
and recheck threads start successfully, display redetection finishes cleanly.

---

**Reproduction attempt 2 — laptop sleep/resume:**

After the above, I put the laptop into sleep mode (lid close). Upon resume, the
internal display (eDP-1) woke normally but the external HDMI monitor remained
off — bug reproduced again.

Running `systemctl --user restart plasma-powerdevil.service` did NOT wake the
external monitor.

**drm_info output (captured while bug was active):**

HDMI-A-1 (Connector 1) shows:
  Status: connected
  DPMS: On
  CRTC_ID: 145 (active, mode [email protected])
  link-status: Good

This means KWin/DRM believes the HDMI output is fully active and is rendering
to it normally — the kernel sees no problem. The monitor is physically not
receiving a signal, but from the software side everything appears operational.

**PowerDevil log captured during the bug (sleep resume):**

  [1304979] Removing connected display on bus 5
  [1304979] (dw_remove_display_by_businfo) No Display_Ref found for i2c bus: 5
  [1304979] Adding connected display with bus 5
  [1304979] Emitting DDCA_EVENT_DISPLAY_CONNECTED, card1-HDMI-A-1, ddc working:
false
  [1304978] ddc became enabled for Display_Ref[47] after 1 milliseconds
  [1304978] Emitting DDCA_EVENT_DDC_ENABLED, card1-HDMI-A-1, ddc working: false
  [611699] Display redetection finished.
  [611699] Unquiescing libddcutil API...

Both DDCA_EVENT_DISPLAY_CONNECTED and DDCA_EVENT_DDC_ENABLED report ddc
working: false. The "ddc became enabled after 1 milliseconds" message is
immediately followed by DDCA_EVENT_DDC_ENABLED still reporting ddc working:
false — suggesting the enable check resolves too quickly before DDC is actually
ready on the bus after resume.

---

**Summary:**

KWin thinks the output is active (DPMS=On, CRTC active with framebuffer
assigned, link-status Good), but DDC never successfully initializes after
resume. This leaves the monitor in a state where it receives no usable signal
despite the kernel reporting the connection as healthy. Physical HDMI
reconnection resets this state and restores normal behavior until the next
sleep/resume cycle.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to