"Unable to read EDID" for VITURE Beast XR glasses (USB-C DP alt-mode), but every userspace I2C-over-AUX read through the driver's own i2c adapter suc

Graphics / Linux Linux
,
1

## Summary

The driver consistently fails to read the EDID of a VITURE Beast XR glasses display
connected via USB-C DP alt-mode, logging:

```
nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DP-0
```

The connector link-trains and lights up, but with no EDID the driver only offers VESA
fallback modes (1024x768/800x600/640x480), which the glasses’ native 1920x1080 panel
cannot display correctly (scrambled image).

The sink’s DDC is demonstrably fine: reading the EDID from userspace through the
**driver’s own /dev/i2c adapter** for that connector succeeds 100% of the time, with
every transfer style I tried, returning a valid, checksum-clean 256-byte EDID
(base block + CTA-861 extension, “VITURE Beast”, native DTD 1920x1080@60, 148.5 MHz).

System

  • Laptop: Razer Blade 16 (hybrid graphics), GPU: RTX 4090 Laptop GPU (AD103M, PCI 01:00.0)
  • OS: Ubuntu 26.04, kernel 7.0.0-27-generic
  • Session: KDE Plasma, Wayland
  • Drivers tested: **580.159.03** and **595.71.05** (closed kernel modules) — identical failure
  • GSP: fails identically with `NVreg_EnableGpuFirmware=1` (default) and `=0`
    (verified via /proc/driver/nvidia/params after reboot)
  • Display: VITURE Beast XR glasses (USB-C, DP alt-mode; USB descriptor 35ca:1201),
    latest device firmware
  • Reproduces on both USB-C ports of the laptop (both are wired to the dGPU)

Evidence: userspace I2C reads through the NVIDIA i2c adapter all succeed

With the glasses connected (connector DP-3/DP-4 depending on port), the corresponding
“NVIDIA i2c adapter N at 1:00.0” bus at slave address 0x50 answers all of the following,
each returning the correct EDID (header `00ffffffffffff00`, both block checksums valid):

Transfer style (via /dev/i2c-N, I2C_RDWR ioctl) Result
Separate transactions: write(offset 0x00), STOP, read 128 EDID OK
Combined transfer: [W 0x50 offset][R 0x50 128] with repeated START EDID OK
E-DDC: [W 0x30 segment=0][W 0x50 offset][R 0x50 128] single combined transaction EDID OK
Bare segment-pointer write to 0x30 ACKed

So I2C-over-AUX to this sink works through the GPU’s AUX hardware — only the driver’s
internal EDID read path fails, and it fails instantly at every hotplug/reprobe, not
intermittently.

Minimal repro for the working read (run as root with the glasses connected, adjust bus
number to the NVIDIA i2c adapter that responds):

```python
import fcntl, os
fd = os.open(“/dev/i2c-18”, os.O_RDWR) # “NVIDIA i2c adapter N at 1:00.0”
fcntl.ioctl(fd, 0x0703, 0x50) # I2C_SLAVE
os.write(fd, bytes([0x00]))
edid = os.read(fd, 128)
assert edid[:8] == bytes.fromhex(“00ffffffffffff00”)
```

Also observed / ruled out

  • Kernel DRM debugfs `edid_override` on the connector is accepted by the DRM core
    (sysfs `edid` then returns the blob) but nvidia-modeset ignores it and keeps the
    VESA fallback mode list.
  • A compositor-injected custom 1920x1080@60 mode (KWin) is rejected: “the driver
    rejected the output configuration”.
  • Since there is no CustomEDID equivalent outside X11, there is **no workaround on
    Wayland** — which makes this failure a hard blocker for this display.
  • Sink EDID has minor conformity quirks per edid-decode (image-size field abuse, one
    unknown display descriptor type 0x18, more Native DTDs than DTDs in the CTA block),
    but both checksums are valid. None of these should prevent the read itself.

Attachments

  • nvidia-bug-report.log.gz (captured with the glasses connected and in the failing state)
  • viture_beast_edid.bin (the 256-byte EDID captured via the driver’s own i2c adapter)
  • edid-decode output of the above

Ask

  1. Fix the EDID read for this sink (or share what the internal DDC sequence does
    differently from the transfers above so Viture can be engaged with specifics).
  2. Independently: please consider honoring the DRM `edid_override` /
    `drm.edid_firmware` mechanisms on Wayland so users aren’t stranded when a sink’s
    EDID can’t be read.

Happy to run instrumented builds, capture AUX traces, or test driver candidates —
the failure is 100% reproducible on this hardware.

viture_beast_edid_decoded.txt (2.3 KB)

nvidia-bug-report.log.gz (545.6 KB)