Summary
android_panel_px() derives the panel's physical size from Android DisplayMetrics.xdpi/ydpi. That is an approximation, and it disagrees with the CNSDK calibration — which is the authoritative value, because it is what the weaver interlaces against.
On the LPD-20W:
calibration (basePanel.pixelSize_mm = 0.0644): 0.0696 x 0.1546 m
DisplayMetrics xdpi/ydpi (386.366 / 388.28): 0.0710 x 0.1570 m <- ~2% larger, both axes
The physical panel size feeds Kooima, so a 2% error is a systematic geometry error across the whole panel.
Why the tablet doesn't show it
The Lume Pad path reports 0.2350 x 0.1470 m, which implies a pitch of 0.0919 / 0.0918 mm/px — square to four decimals, i.e. genuinely calibration-derived. Android's own dpi on that device (320) would have given 0.1270 x 0.2032 m, nothing like it. So the working configuration has always been calibration-derived; only the newer device-query path introduced the dpi approximation.
The problem with the obvious fix
Reading the calibration JSON directly from the plug-in does not work, and this is worth recording so nobody re-tries it:
/data/data/com.leialoft.display.config/files/displayConfig.json — another app's private dir./sdcard/displayConfig.json — blocked by scoped storage without MANAGE_EXTERNAL_STORAGE./data/media/0/... — root only.
Attempted and confirmed inert: the reader never fired and display_info kept the dpi-derived value.
So the pitch has to come from CNSDK itself. The wrinkle is timing: get_display_info() is answered at xrCreateInstance, before the async CNSDK core is up, which is exactly why the device query exists.
Options
- Have the DP re-publish display geometry once the CNSDK core is up, and let the runtime refresh — best correctness, needs a refresh path.
- Keep
xdpi/ydpi as the boot-time estimate but correct it from CNSDK when the core lands (same as (1), framed as a correction rather than a republish).
- Read the pitch through whatever synchronous CNSDK config accessor exists in
leia/core/deviceConfig.h before core init, if one does.
Impact
Unquantified. It is a real geometry error, but it was not the cause of the browser double-image being chased when this was found (see displayxr-browser#165) — the model viewer weaves and head-tracks correctly on this phone with the dpi-derived value in place. Worth fixing on correctness grounds; not known to be user-visible on its own.
Summary
android_panel_px()derives the panel's physical size from AndroidDisplayMetrics.xdpi/ydpi. That is an approximation, and it disagrees with the CNSDK calibration — which is the authoritative value, because it is what the weaver interlaces against.On the LPD-20W:
The physical panel size feeds Kooima, so a 2% error is a systematic geometry error across the whole panel.
Why the tablet doesn't show it
The Lume Pad path reports
0.2350 x 0.1470 m, which implies a pitch of 0.0919 / 0.0918 mm/px — square to four decimals, i.e. genuinely calibration-derived. Android's own dpi on that device (320) would have given0.1270 x 0.2032 m, nothing like it. So the working configuration has always been calibration-derived; only the newer device-query path introduced the dpi approximation.The problem with the obvious fix
Reading the calibration JSON directly from the plug-in does not work, and this is worth recording so nobody re-tries it:
/data/data/com.leialoft.display.config/files/displayConfig.json— another app's private dir./sdcard/displayConfig.json— blocked by scoped storage withoutMANAGE_EXTERNAL_STORAGE./data/media/0/...— root only.Attempted and confirmed inert: the reader never fired and
display_infokept the dpi-derived value.So the pitch has to come from CNSDK itself. The wrinkle is timing:
get_display_info()is answered atxrCreateInstance, before the async CNSDK core is up, which is exactly why the device query exists.Options
xdpi/ydpias the boot-time estimate but correct it from CNSDK when the core lands (same as (1), framed as a correction rather than a republish).leia/core/deviceConfig.hbefore core init, if one does.Impact
Unquantified. It is a real geometry error, but it was not the cause of the browser double-image being chased when this was found (see
displayxr-browser#165) — the model viewer weaves and head-tracks correctly on this phone with the dpi-derived value in place. Worth fixing on correctness grounds; not known to be user-visible on its own.