Panel physical size and refresh disagree between init paths (0.344x0.194 m / 60 Hz on a 27" 165 Hz Odyssey 3D)

[dfattal]

Summary

On a Samsung Odyssey 3D (G90XF / SAM7861, 27", 3840x2160 @ 165 Hz) two plug-in init paths report different physical sizes and different refresh rates for the same panel, and one of them is badly wrong.

WARN [leia_hmd_create]     Created Leia 3D display: 3840x2160 px, 0.344x0.194 m, nominal Z=0.65 m, 60.0 Hz
WARN [create_sr_context]   SR D3D11 display (modern API): 2560x1440 px, physical 59.67cm x 33.57cm = 0.5967m x 0.3357m
WARN [leiasr_static_get_display_dimensions] Static display dimensions: 59.67cm x 33.57cm = 0.5967m x 0.3357m

Path	Physical size	Implied diagonal	Refresh
leia_hmd_create	0.344 x 0.194 m ❌	15.5"	60.0 Hz ❌
create_sr_context / leiasr_static_get_display_dimensions	0.5967 x 0.3357 m ✅	27.0" ✅	—

0.344 x 0.194 m is a 15.5" diagonal on a 27" panel — a ~1.73x error. It looks like a small-panel/Lume-Pad-class default rather than anything derived from this display. 60.0 Hz is likewise wrong on a 165 Hz panel (EnumDisplaySettingsW confirms 3840x2160 @ 165Hz; available 4K rates are 59/60/120/165).

Kooima projection is driven by physical size over pixel pitch, so whichever value the projection path consumes decides whether geometry is right.

The 1920x1080 per eye number is right only because two errors cancel

WARN [create_sr_context] SR recommended view texture: 1920x1080 per eye

This currently looks correct, but it is 0.5 x the logical 2560x1440... which happens to equal 0.5 x the true 3840x2160/2 arrangement. Fixing either input in isolation will make this number wrong. Please treat the pixel source and the physical-size source as one change, and re-derive the recommended view texture from the corrected values rather than trusting that it currently matches.

Related, and the reason the pixel column above is muddled

create_sr_context reporting 2560x1440 is a separate, already-filed issue — the host process is not DPI-aware, and this box runs at 150% scaling (3840/1.5 = 2560, 2160/1.5 = 1440). Filed on the runtime side as DisplayXR/displayxr-runtime#1201. Real DPI-aware apps get the correct 3840x2160, so that half is not a plug-in bug.

The physical-size and refresh-rate disagreement in this issue is independent of DPI and reproduces regardless of the host's DPI awareness — a DPI-aware app still logs 0.344x0.194 m / 60.0 Hz from leia_hmd_create.

Reproduction

"C:\Program Files\DisplayXR\Runtime\displayxr-cli.exe" info

or launch any DisplayXR app and read %LOCALAPPDATA%\DisplayXR\DisplayXR_<exe>.<pid>_*.log.

Environment

• Plug-in: DisplayXR Leia SR v2.5.0 (ABI v5, loader-verified). Also reproduced on v2.3.0 — unchanged across the 2.3.0 -> 2.5.0 update.
• Runtime: v2.12.1
• SR Platform 1.34.12, LeiaSR Tracker 1.10.1 (plug-in falls back to the legacy C++ v1 SR API here: srCreateInstance failed (-4))
• Panel: Samsung Odyssey 3D G90XF, EDID SAM7861, 3840x2160 @ 165 Hz, 150% DPI scaling
• Host: Windows 11 Pro 26200, i9-12900K, RTX 2080 Ti (render) + Intel UHD 770 (panel scanout — split-adapter)

Note edid_reads=0 in the probe line — the monitor is correlated but no EDID blob is actually read, so neither the physical size nor the refresh appears to come from EDID on this box:

WARN [leia_edid_probe_display] EDID probe: gdi_monitors=1 setupdi_devices=1 edid_reads=0 correlated=1 diag=0 win32err=0

That may be the common root for both the size and the refresh being defaults rather than measured values.

---

Filed from the odyssey-lab test box at David's request (Slack #tmp-odyssey-lab).

[dfattal]

Severity raise: this wrong value reaches frame pacing, not just a log line

Per @dfattal (verified in code): the 60.0 Hz this plug-in reports in leia_hmd_create is passed as sr_refresh_rate_hz into null_compositor_create_system_with_dims(...) at target_instance.c:354. The null compositor is the system-level xrt_system_compositor on every path, and it faithfully echoes whatever the DP hands it:

WARN [t_instance_create_system] Null-compositor frame pacing: 60.00 Hz
INFO [null_compositor_create_system_with_dims] Using display refresh rate: 60 Hz (interval: 16666666 ns)

On this 165 Hz panel the correct interval is ~6.06 ms; the runtime is being told 16.67 ms.

So the two symptoms originally filed as separate observations — the bogus 60.0 Hz in leia_hmd_create, and the null compositor's 60.00 Hz pacing — are the same defect seen twice, one layer apart. That changes the severity: this is not a cosmetic log discrepancy, it is a wrong refresh rate propagating from the plug-in into the runtime's frame-pacing interval.

The physical-size half of this issue (0.344 x 0.194 m) is the same shape of problem: a default that never gets replaced by a measured value, most likely explained by the edid_reads=0 in the probe line. Worth fixing size and refresh together, from the same source.

Unchanged from the original report: reproduces on both v2.5.0 and v2.3.0, and is independent of the DPI/host-awareness issue tracked as runtime#1201.