DaVinci Resolve

DaVinci Resolve

Resolve is not shipped with SynapseOS — it is proprietary and the download is behind a registration form. What SynapseOS ships is syn resolve, which handles the parts after the download that otherwise cost an afternoon.

syn resolve doctor              What is installed, what is missing (default)
sudo syn resolve setup          Apply the fixes: OpenCL runtime + launch environment
syn resolve install [zip]       Build the AUR package from a downloaded zip
syn resolve transcode <file>…   Rewrap footage the free edition can read
syn resolve launch [args]       Run Resolve with the SynapseOS launch environment

Start with syn resolve doctor. It is read-only and it answers, in order, every question people actually ask when Resolve misbehaves.

---

What this does not do, because upstream already does

Most "Resolve on Arch" advice is about problems the AUR davinci-resolve package already solves. It deletes the bundled libglib/libgio/libgmodule/ libgobject/libc++ that shadow the system copies and symlinks the real ones in, patches an RPATH onto every ELF it ships, and installs Blackmagic's udev rules for panels, keyboards and DeckLink cards.

Re-applying any of that by hand fights the package. syn resolve deliberately covers only what is left.

---

Installing it

The download is manual and always will be — Blackmagic require a registration and a licence acceptance that nothing should click through on your behalf. Get the Linux .zip from Blackmagic, leave it in ~/Downloads, then:

syn resolve install

It finds the newest DaVinci_Resolve*_Linux.zip, works out from the filename whether it is the free or Studio edition (they are separate AUR packages and they conflict), clones the right AUR repo, stages the archive and builds it. Pass a path explicitly if the zip is elsewhere.

It stops and asks before building, because building an AUR package means running its PKGBUILD as a script.

The version-mismatch trap

The AUR PKGBUILD pins both pkgver and the archive's sha256. Download a version it does not expect and makepkg fails deep inside on a checksum error that names neither cause.

The AUR routinely lags Blackmagic by days, so this is common, and "download the older version instead" is usually the wrong advice. syn resolve install catches it up front and prints the exact two lines to change:

VERSION MISMATCH — makepkg would fail this on a checksum:
    your archive  : 20.1.1
    PKGBUILD wants: 20.1.0

    pkgver=20.1.1
    sha256sums=('…'   # first entry, the .zip

The hash is computed for you, because it is the only part you cannot look up and on a 4 GB archive it is the slow half of the answer. Nothing else in the PKGBUILD is version-specific.

---

OpenCL — the one that actually breaks installs

If Resolve installs cleanly and then refuses to start, this is why.

/opt/resolve/bin/resolve has libOpenCL.so.1 in its NEEDED. OpenCL is not optional acceleration here, it is a link-time dependency. The AUR package asks for the virtual opencl-driver, which several packages provide — and a virtual dependency with more than one provider is resolved by picking one, not by asking. Install non-interactively and a machine can end up holding an ICD for a GPU it does not have.

It fails late and quietly: the package installs perfectly, and Resolve then refuses to start and blames the GPU.

syn resolve setup installs the concrete one for the GPU actually present:

GPU	Package
NVIDIA	opencl-nvidia
AMD	rocm-opencl-runtime
Intel	intel-compute-runtime

The test is the ICD file, not the package. /etc/OpenCL/vendors/*.icd is what the OpenCL loader actually reads, so that is what doctor checks — a package can be installed and still leave no usable ICD, and an ICD can be present from something else entirely. doctor warns about that case specifically: a runtime present, but not the one matching your GPU.

ls /etc/OpenCL/vendors/        # what the loader will find
clinfo -l                      # what it resolves to, if clinfo is installed

Resolve also needs a real GPU. doctor says so if it finds no PCI display controller at all, which is the usual answer in a VM.

---

The launch environment

sudo syn resolve setup writes /usr/local/share/applications/DaVinciResolve.desktop, which shadows the entry the AUR package installs into /usr/share/applications. /usr/local/share comes first in XDG_DATA_DIRS, so the override wins for menu launches.

Shadowing rather than editing, for three reasons: an upgrade cannot revert it, deleting one file undoes it completely, and editing the packaged entry would fight pacman on every upgrade. A wrapper in /usr/bin was not an option either — it would file-conflict with the AUR package's own symlink.

The override changes exactly one line: Exec= becomes /usr/lib/syn/syn-resolve launch. Everything else — Name, Icon, MimeType, StartupWMClass — survives untouched. The rewrite is anchored to ^Exec=, so a TryExec line is deliberately left pointing at the real binary where one exists: that is the menu's "is this actually installed" probe, and redirecting it would make the entry claim Resolve is present whenever syn is.

So the environment lives in syn resolve launch, which means running that command by hand gets you an identical launch to clicking the menu entry. It:

• exports QT_QPA_PLATFORM=xcb. Resolve is X11-only Qt5, so it lands on Xwayland regardless — this makes it a decision rather than a fallback, so every launch is the same launch.
• unsets QT_QPA_PLATFORMTHEME and QT_STYLE_OVERRIDE. SynapseOS exports the first session-wide so Qt apps pick up the theme. Resolve bundles its own Qt 5.15 and ships no platformthemes plugin, so the variable can only point it at the system's. Measured rather than assumed, and weaker than the guides claim: the bundled Qt's compiled-in prefix is a dead build path and QT_PLUGIN_PATH is unset, so today it almost certainly reaches nothing. Cleared anyway, because it costs one line and the day it does resolve it would mean two different Qt 5.15 builds in one process.

Two things it deliberately does not touch. MANGOHUD is exported session-wide and looks like it must reach an application this GPU-heavy, but MangoHud's implicit layer is Vulkan-only and Resolve links libGL and libOpenCL with no Vulkan anywhere — so clearing it would be a fix for nothing. And no Qt scaling variables are set: Resolve has its own UI scaling preference (Preferences ▸ User ▸ UI Settings), and Qt scaling applied underneath it fights that setting rather than helping.

A pacman hook re-runs syn resolve setup --quiet after upgrades, so the override survives. That path only ever reports — it never installs anything, because pacman holds its database lock for the whole transaction and a hook shelling out to pacman would deadlock against the transaction that invoked it.

---

Codecs: what the free edition can read

The free edition of Resolve on Linux decodes neither H.264 nor H.265, nor AAC. Footage from phones, most cameras, and any ordinary screen recording imports as media offline.

This is a licensing limit inside Resolve, not a missing codec on your system. No package you install changes it. Studio does decode H.264/H.265, and doctor says which edition you have.

The way round it is to rewrap:

syn resolve transcode ~/Videos/clip.mp4

That writes a DNxHR .mov into a DNxHR/ folder beside the original — import that. Audio becomes PCM in the same pass, which matters for the same reason: an .mov with AAC in it is as unimportable as the H.264 was.

Option	Effect
--profile dnxhr_lb	Proxy/offline grade — much smaller
--profile dnxhr_sq	Standard quality (default)
--profile dnxhr_hq	High quality
--profile dnxhr_hqx	10-bit; needs a 10-bit source
--out <dir>	Write somewhere other than DNxHR/
--fps <rate>	Override the frame rate it conforms to

Variable-rate sources

Screen recordings are captured on damage — a frame only when the screen changes — so they have no single frame rate, and no timeline can hold that. transcode conforms them to the nearest standard rate and says what it did:

variable rate (avg 67.20 fps) → constant 60
313 frames → 281 at 60 fps

Frames genuinely are dropped when an oddly-rated source becomes 60, and that is the point: uniformly, instead of wherever the source happened to be dense.

SynapseOS recordings are captured at a constant 60 fps as of 0.2.7, so new ones conform without losing anything. If a recording is going straight into an edit, Control panel ▸ Sound ▸ Record for editing captures DNxHR directly and skips the conversion — and the extra compression generation — at about 1 GB a minute. See The Desktop and Troubleshooting.

---

Related

• Troubleshooting — symptom-first entries for recordings that will not import
• Commands — the rest of the syn command-line surface
• Gaming — the other place GPU drivers and OpenCL/Vulkan runtimes matter