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

            Bug ID: 523768
           Summary: DDC/CI brightness not detected on DisplayPort/USB-C
                    outputs while it works on HDMI (amdgpu)
    Classification: Plasma
           Product: kwin
      Version First 6.6.5
       Reported In:
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: platform-drm
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]
  Target Milestone: ---

SUMMARY

On the same machine, in the same session, KWin detects DDC/CI brightness
control on an HDMI-connected monitor but not on a monitor connected over USB-C
(DisplayPort Alt Mode). For the DisplayPort output, KWin falls back to software
brightness, which scales down framebuffer values instead of dimming the panel.
That visibly reduces both brightness and contrast, and the monitor's own
brightness setting never changes.

DDC/CI itself works fine on that output: ddcutil reads and writes VCP codes
reliably over the connector's AUX i2c adapter (10 of 10 setvcp calls
succeeded).

STEPS TO REPRODUCE

1. Connect an external monitor over USB-C (DisplayPort Alt Mode) to an amdgpu
system.
2. Connect a second external monitor over HDMI (can be at a different time;
both are remembered in kwinoutputconfig.json).
3. Inspect ~/.config/kwinoutputconfig.json and compare the detectedDdcCi field
per output.

OBSERVED RESULT

connectorName  monitor                   allowDdcCi  detectedDdcCi 
allowSdrSoftwareBrightness
HDMI-A-1       LEN 26824 (Lenovo)        true        true           false
DP-1           DEL 61815 (Dell S2725DC)  true        false          true
HDMI-A-1       ENC 12338                 true        false          true
eDP-1          BOE 3423 (internal)       true        false          false

The HDMI-connected Lenovo gets real DDC/CI brightness control. The USB-C
connected Dell does not, and is software-dimmed instead.

EXPECTED RESULT

DDC/CI is detected on the DisplayPort/USB-C output as well, since the monitor
responds to DDC/CI on that connection.

SOFTWARE/OS VERSIONS

Operating System: TUXEDO OS (Ubuntu 24.04 base)
KDE Plasma Version: 6.6.5
KWin: 6.6.5 (package 4:6.6.5-0ubuntu0.1~tux1)
Qt Version: 6.10.2
Kernel Version: 6.17.0-124040-tuxedo
Graphics Platform: Wayland
GPU: AMD Radeon 880M, Strix (1002:150e), amdgpu
Mesa: 26.1.4
Monitor: Dell S2725DC, 2560x1440@144Hz, connected over USB-C DisplayPort Alt
Mode

ADDITIONAL INFORMATION

DDC/CI works on this output when the correct i2c adapter is used. The connector
exposes two different i2c adapters, and only one of them carries DDC:

/sys/class/drm/card1-DP-1/ddc      -> i2c-7   "AMDGPU DM i2c hw bus 2"
/sys/class/drm/card1-DP-1/i2c-15   -> i2c-15  "AMDGPU DM aux hw bus 2"

Probing both with ddcutil:

ddcutil --bus 7  --terse getvcp 10   ->  No monitor detected on bus /dev/i2c-7
ddcutil --bus 15 --terse getvcp 10   ->  VCP 10 C 100 100

So the "ddc" symlink of the connector points at the physical GPIO i2c bus,
which is unconnected on a USB-C/DisplayPort link, while DDC actually runs over
the AUX channel that the kernel exposes as the "i2c-15" subdirectory of the
connector. On HDMI there is no such subdirectory and the "ddc" symlink is the
correct adapter, which matches the observation that HDMI works and DisplayPort
does not.

Hypothesis, offered with the caveat that I could not verify it from the
binaries: KWin resolves the DDC adapter through the connector's "ddc" symlink,
which is the wrong adapter for DisplayPort on amdgpu. I found no /dev/i2c,
i2c-dev or drm_dp_aux string literals in kwin_wayland or libkwin.so.6, and
kwin_wayland links only against libdrm, so I could not confirm the code path
from the outside. The observations above hold regardless of the explanation.

Side note on the fallback: for an output where DDC/CI is not detected,
allowSdrSoftwareBrightness is enabled. Lowering brightness then degrades the
image (reduced brightness and contrast) rather than dimming the backlight,
which users are likely to perceive as a washed out picture rather than as a
dimmer one. It might be worth reconsidering that fallback for external
monitors, or making it discoverable in the UI.

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

Reply via email to