Public bug reported:
[ Impact ]
On Ubuntu 26.04 LTS, `libdisplay-info` 0.3.0 does not parse CTA-861 data
blocks embedded in DisplayID v2 extensions. Modern internal OLED laptop
panels commonly advertise BT.2020 colorimetry, SMPTE ST 2084/PQ and HDR
static metadata in this location.
As a result, KWin incorrectly reports physically HDR-capable displays as
incapable. Plasma's HDR and Wide Color Gamut controls are therefore
absent, and affected users can only use the simulated EDR path.
Applications which check the compositor's output capabilities may also
hide their HDR options.
This is reproducible on an Acer Swift SF16-71T with a Samsung Display
ATNA60CL11-0 OLED panel. The EDID advertises:
* 10-bit RGB output
* BT.2020 RGB colorimetry
* SMPTE ST 2084/PQ
* HDR static metadata type 1
* approximately 616.9 cd/m² peak and 400 cd/m² frame-average luminance
The kernel `xe` DRM driver exposes `max bpc`, `Colorspace`, and
`HDR_OUTPUT_METADATA` on the internal eDP connector, so the remaining
failure is userspace EDID interpretation.
Current result with Ubuntu's package:
```
$ dpkg-query -W -f='${binary:Package} ${Version}\n' 'libdisplay-info3:*'
libdisplay-info3:amd64 0.3.0-1
libdisplay-info3:i386 0.3.0-1
$ kscreen-doctor -o
...
HDR: incapable
Wide Color Gamut: incapable
...
Allow EDR: always
```
However, `edid-decode /sys/class/drm/card1-eDP-1/edid` finds the nested
block:
```
CTA-861 DisplayID Data Block:
Colorimetry Data Block:
BT2020RGB
HDR Static Metadata Data Block:
Electro optical transfer functions:
Traditional gamma - SDR luminance range
SMPTE ST2084
Supported static metadata descriptors:
Static metadata type 1
Desired content max luminance: 116 (616.884 cd/m^2)
Desired content max frame-average luminance: 96 (400.000 cd/m^2)
```
Upstream KDE bug 499673 identifies the same cause. Upstream confirmed
that the issue is fixed by libdisplay-info 0.4.0 and closed the KDE
report as resolved upstream:
https://bugs.kde.org/show_bug.cgi?id=499673
[ Upstream Fix ]
The relevant upstream work adds CTA-861 parsing inside DisplayID v2 and
makes the high-level `di_info` APIs search those nested blocks. Upstream
release:
https://gitlab.freedesktop.org/emersion/libdisplay-info/-/tree/0.4.0
The minimal upstream stack tested on top of 0.3.0 is, in order:
```
0dee020 test: add asus-ux3405
788c056 displayid2: decode data blocks structure
d535192 cta: introduce struct di_cta
34b3635 cta: make di_cta.flags optional
4713505 cta: expose _di_cta_data_block_{parse,destroy}
7324cca displayid2: add support for CTA-861 data blocks
73ab82d info: don't use di_ prefix for static helpers
73ec53d info: search CTA blocks in DisplayID v2 extensions
```
This stack passes all 66 upstream tests. Through the high-level API, the
attached panel EDID changes from `PQ=no`, zero HDR luminance and no
BT.2020 signal colorimetry to `PQ=yes`, `BT2020_RGB`, 616.884 cd/m² peak
luminance and 400 cd/m² maxFALL.
Commit `7324cca` adds the public accessor
`di_displayid2_data_block_get_cta_data_blocks()`. This is an additive
exported symbol even when the backport retains SONAME 3, so the proposed
package should be checked with an ABI comparison in addition to the test
suite. Later parser-safety fixes from the 0.4.0 cycle should also be
reviewed when preparing the final patch stack.
A stable-release update is justified because this restores already-
advertised hardware functionality on a class of modern OLED laptops. A
targeted backport can retain SONAME 3 and avoid breaking existing
SONAME-3 consumers.
[ Test Plan ]
1. Use Ubuntu 26.04 LTS with the archive version of `libdisplay-info3`
on a machine whose EDID places HDR metadata in a CTA-861 block nested in
DisplayID v2. The attached `edid.bin` can be used as a parser regression
fixture when the physical panel is unavailable.
2. Before installing the proposed package, run:
```
dpkg-query -W libdisplay-info3
di-edid-decode /sys/class/drm/card1-eDP-1/edid
edid-decode /sys/class/drm/card1-eDP-1/edid
kscreen-doctor -o
```
Confirm that the libdisplay-info 0.3.0 `di-edid-decode` output stops at
the DisplayID v2 extension without showing its nested CTA-861
HDR/colorimetry blocks, while the independent `edid-decode` tool shows
BT2020RGB and SMPTE ST2084 metadata from the same EDID. Confirm that
`kscreen-doctor` reports `HDR: incapable` and `Wide Color Gamut:
incapable`.
3. Install every currently installed architecture of the candidate from
`resolute-proposed`, together with the matching utility package. On the
reproducing machine these are:
```
sudo apt install libdisplay-info3:amd64 libdisplay-info3:i386
libdisplay-info-bin
apt-cache policy libdisplay-info3:amd64 libdisplay-info3:i386
libdisplay-info-bin
dpkg-query -W -f='${binary:Package} ${Version}\n' 'libdisplay-info3:*'
libdisplay-info-bin
```
Record the candidate version and confirm that the amd64 and i386 `Multi-
Arch: same` packages have identical versions. Then reboot or log out and
start a new Plasma Wayland session so KWin loads the updated library.
4. Run `kscreen-doctor -o` again. Confirm that the HDR and Wide Color
Gamut fields no longer say `incapable`, and that System Settings >
Display & Monitor shows the HDR control.
5. Only on a machine with a known-good secondary output or another
tested recovery method, enable HDR in System Settings. Confirm that
`kscreen-doctor -o` reports HDR enabled; the display remains active at
its native mode; colors, SDR desktop content and brightness remain
usable; and disabling HDR returns cleanly to SDR. If the internal output
becomes unusable, recover from the secondary output with:
```
kscreen-doctor output.eDP-1.hdr.disable output.eDP-1.wcg.disable
```
Testers without a safe recovery output should stop after capability
detection in step 4 rather than risk losing the only visible output.
6. Add the attached EDID to the proposed source package's high-level
`di-edid-print` golden regression tests. The expected result must
include `PQ=yes`, `BT2020_RGB`, approximately 616.884 cd/m² peak
luminance and 400 cd/m² maxFALL. If the decoder-printing commits are
included too, separately require `di-edid-decode edid.bin` to show the
nested Colorimetry and HDR Static Metadata blocks.
7. Build the proposed source package with tests enabled:
```
dpkg-buildpackage -b -uc -us
```
The build-time Meson suite must complete with zero failures. It must
cover ordinary CTA-861 extensions, CTA-861 nested in DisplayID v2,
DisplayID v2 without CTA-861, and malformed/truncated CTA or DisplayID
block lengths. The current no-op package autopkgtest should not be
treated as evidence for these parser cases.
8. On available test hardware, regression-test an ordinary external SDR
monitor and an external HDR monitor, confirming that capability
detection remains correct and parsing does not crash.
[ Where problems could occur ]
The change affects EDID/DisplayID parsing used by compositors, media
players, Mesa components and diagnostic tools. A parser regression could
reject EDIDs which currently parse, read malformed block lengths
incorrectly, crash on malformed data, or report incorrect
colorimetry/luminance.
Incorrectly reporting HDR or BT.2020 support could cause KWin to expose
controls for an unsupported display. If a user then enables HDR, this
could produce a blank output, incorrect colors, clipping, or an unusable
brightness level until the mode is reverted.
These risks should be mitigated by keeping the Resolute change to a
reviewed upstream parser stack, retaining SONAME 3 so existing consumers
continue to load, checking the additive symbol/API change with an ABI
comparison, running the complete upstream parser tests, adding the
attached affected EDID as a high-level regression test, and testing
ordinary CTA, nested DisplayID CTA, malformed EDIDs, SDR outputs and HDR
outputs.
[ Other Info ]
System information for the reproducing machine:
```
Ubuntu 26.04 LTS (Resolute)
KDE Plasma / KWin 6.6.5, Wayland
Linux 7.0.0-28-generic
Intel Panther Lake Arc B390, xe DRM driver
Acer Swift SF16-71T
Samsung Display ATNA60CL11-0 OLED, 2880x1800@120 Hz
libdisplay-info3 0.3.0-1
```
The attached DRM information confirms that eDP-1 provides all KMS
properties KWin requires:
```
max bpc: range [6, 12], current 10
Colorspace: includes BT2020_RGB
HDR_OUTPUT_METADATA: present
```
libdisplay-info 0.4.0 changes the SONAME from `libdisplay-info.so.3` to
`.so.4`. Therefore, importing 0.4.0 wholesale into Resolute would
require a library transition and rebuilding reverse dependencies. The
safer stable-release approach is a targeted DisplayID-v2 nested CTA
parser backport to 0.3.0 which retains SONAME 3.
At the time of filing, the active Ubuntu development series (Stonking)
also publishes 0.3.0-1 and is not yet fixed. This currently blocks SRU
acceptance: the development-series task must first be fixed and marked
Fix Released, after which the targeted Resolute SRU can proceed.
ProblemType: Bug
DistroRelease: Ubuntu 26.04
Package: libdisplay-info3 0.3.0-1
ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12
Uname: Linux 7.0.0-28-generic x86_64
ApportVersion: 2.34.1-0ubuntu0.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
Date: Sat Jul 25 19:41:01 2026
InstallationDate: Installed on 2026-07-24 (1 days ago)
InstallationMedia: Kubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423)
SourcePackage: libdisplay-info
UpgradeStatus: No upgrade log present (probably fresh install)
** Affects: libdisplay-info (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug resolute wayland-session
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2161800
Title:
libdisplay-info 0.3.0 misses HDR metadata in CTA-861 blocks nested in
DisplayID v2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libdisplay-info/+bug/2161800/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
