From 0cf503d01e1dc30da4919807b49782b9b250f476 Mon Sep 17 00:00:00 2001 From: Simon Lambin Date: Wed, 9 Sep 2026 20:40:41 +0000 Subject: [PATCH] doc: confirm davinci is working --- davinci/CLAUDE.md | 52 ++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 49 insertions(+), 3 deletions(-) diff --git a/davinci/CLAUDE.md b/davinci/CLAUDE.md index 51fc737..b1a5b8e 100644 --- a/davinci/CLAUDE.md +++ b/davinci/CLAUDE.md @@ -159,6 +159,50 @@ not an actual GUI launch. compute on real AMD/Intel hardware, audio, the app-menu-entry steps, Studio+dongle path. All of that needs a real Linux host with distrobox. +## Real GUI launch test (2026-09-09) + +Simon ran `distrobox create` + `davinci-run` for real, `amd` target, on +actual Linux/GPU hardware (AMD Radeon 680M integrated GPU, `rocm-opencl` + +`intel-compute-runtime` both present as installed by the `amd` stage) — +the one thing the Docker Desktop/WSL2 build test above explicitly could not +cover. Result: **it works.** `davinci-run` launched `/opt/resolve/bin/resolve`, +which went through the v21 "what's new" popup → Project Manager → Create +New Project → a Transcode window, all mapped and focused normally under +Hyprland (XWayland, confirmed via `hyprctl clients`). This is the first +confirmation of the full stack (distrobox create → box → `davinci-run` → +real GPU) actually working end to end, not just the image build. + +- **False alarm during my own debugging, worth recording so it isn't + re-chased:** my first few attempts ran `davinci-run | head -N` to inspect + output, which reproduced `Failed to create application support + directories` every time (plus `log4cxx: No appender could be found`). + This looked exactly like a real startup bug and cost real debugging time + (strace, permission checks, `getpwuid`/nsswitch checks, `QT_PLUGIN_PATH` + host-env-leak theory — all dead ends). The actual cause: `head -N` closes + its end of the pipe after N lines, sending Resolve's process group a + SIGPIPE that kills a startup helper before it finishes setting up its + app-support directories. Piping through `tail` instead (which reads to + EOF, no early close) or not piping at all made the error disappear + immediately, every time. **Lesson: never pipe `davinci-run`'s stdout + through something that can close its read end early (`head`, `sed -q`, + etc.) when diagnosing a "failed to start" report — redirect to a file or + use `tail` instead, or the pipe itself becomes the bug.** +- Real host environment leaking into the box (Nix/home-manager: `QT_PLUGIN_PATH`, + `PATH`, `XDG_DATA_DIRS` all full of `/nix/store/...` entries) turned out + to be harmless for Resolve itself — it uses its own bundled Qt5 via + `DT_RPATH` regardless of `QT_PLUGIN_PATH`. Not something `davinci-run` + needs to guard against. +- **No audio confirmed for real, as predicted in the README's "Known + gotchas":** `ResolveDebug.txt` is full of `ALSA lib dlmisc.c:339: + (snd_dlobj_cache_get0) [error.core] Cannot open shared library + libasound_module_pcm_pipewire.so` — the host's PipeWire ALSA plugin is a + Nix store path the box can't see. Not investigated further since the + README already documents the fix (swap to `alsa-plugins-pulseaudio` + inside the box); this just confirms the gotcha is real, not hypothetical. +- Not covered by this test: actually opening/editing a real project, + playback, OpenCL compute correctness, NVIDIA path (this host is AMD), + Studio+dongle, app-menu-entry end-to-end. + ## What's still unverified after this build test | Area | Confidence | Note | @@ -168,10 +212,12 @@ not an actual GUI launch. | patchelf fix (paths, not sonames) | High | Build-confirmed: ran without failing the build, `--print-needed` shows the entries landed on `resolve` and siblings. | | Dependency sufficiency for the actual entry point (`ldd /opt/resolve/bin/resolve`) | High | Build-confirmed: zero missing libraries. | | AppImage magic-bytes workaround (fat-tire's Arch/Manjaro-specific issue) | Not ported | Not hit with the 21.1 `.run` tested here; add back from fat-tire/resolve's Dockerfile if a future version's `--appimage-extract` fails on it. | -| `amd` variant (ROCm + Intel packages install) | High | Build-confirmed: `dnf install intel-compute-runtime rocm-opencl` succeeded with no extra repos needed. Actual GPU compute correctness (OpenCL kernels running right) still unverified — needs real hardware. | -| `nvidia` variant / `--nvidia` vs CDI | Low | Still a real open question — see "NVIDIA gotcha" in README. Image builds fine either way; only the *runtime* GPU passthrough method is unverified. | +| `amd` variant (ROCm + Intel packages install) | High | Build-confirmed at Docker-build time, and now real-hardware-confirmed: `davinci-run` launched successfully on an AMD Radeon 680M host with `rocm-opencl`/`intel-compute-runtime` installed, 2026-09-09. OpenCL kernel *compute correctness* (actual color-science rendering) still not specifically checked — only that Resolve starts and its windows render normally. | +| `nvidia` variant / `--nvidia` vs CDI | Low | Still a real open question — see "NVIDIA gotcha" in README. Image builds fine either way; only the *runtime* GPU passthrough method is unverified. The 2026-09-09 real-hardware test above was AMD, not NVIDIA. | | App menu entry steps | Medium | Directly adapted from a working upstream script, simplified; confirmed the `.desktop` files exist at the documented paths (`/opt/resolve/share/*.desktop`), not run end-to-end. | -| Actual GUI launch / rendering / audio / licensing | Untested | Needs a real Linux host with distrobox + GPU — impossible to test from this Windows/Docker Desktop environment. | +| Actual GUI launch (`distrobox create` + `davinci-run`) | High | Real-hardware-confirmed 2026-09-09 on AMD/Hyprland: reached Project Manager → Create New Project → Transcode window, all mapped/focused normally. See "Real GUI launch test" above. | +| Audio | Low (confirmed broken as predicted) | `ResolveDebug.txt` shows the exact `libasound_module_pcm_pipewire.so` failure the README's "Known gotchas" section already predicted. Fix documented there, not yet applied/tested. | +| Rendering correctness / playback / licensing / project work | Untested | The 2026-09-09 test only confirmed the app starts and its dialogs render — no project was opened, no clip played back, no license flow exercised. | ## Repo-wide conventions