DaVinci Resolve is a professional video editing suite, but getting it running on Arch-based distros like Omarchy can be a little tricky. The AUR package is broken out of the box: yay -S davinci-resolve will fetch a PKGBUILD that expects Blackmagic’s Linux zip to already be sitting in the build directory, and Blackmagic will not let the AUR legally mirror that zip. Here’s the workaround, why each step exists, and what to do when Resolve installs but refuses to show a window.

I use this on Omarchy (Hyprland) and on a more traditional Arch + NVIDIA workstation. The zip dance is the same. GPU runtime is not.

If you are on Linux Mint instead, the Debian path is in YOUR ULTIMATE Linux Mint 21.3 Install Guide. On Rocky, see The Ultimate Rocky Linux Install Guide. This post is specifically Arch / Omarchy + AUR.

What “broken out of the box” actually means

The AUR davinci-resolve package is a packaging script, not a redistributable of Resolve. Blackmagic requires a form on their support site before you can download the Linux archive. The PKGBUILD’s source= array lists that zip by filename. When yay cannot download it, the build fails with a hash/source error. That is expected. You are not doing anything wrong.

The fix is: let yay clone the PKGBUILD once (the fail is fine), put the zip where makepkg looks, run the same yay command again.

Prerequisites

  • Omarchy or Arch x86_64, up to date (sudo pacman -Syu).
  • yay (or paru) installed. Omarchy typically has an AUR helper ready; on vanilla Arch see the yay bootstrap in the Arch NVIDIA workstation post.
  • Disk space: the zip is large, the extracted tree under /opt/resolve is larger, and Resolve’s scratch/cache wants its own breathing room. A small laptop SSD that is already 90% full is a bad Resolve host.
  • A GPU with a real driver. Nouveau or a missing ROCm/OpenCL stack will install the app and then give you a blank screen or an immediate exit.
  • Hyprland/Omarchy: an XWayland-capable session. Resolve on Linux is not a perfect Wayland citizen. If the UI is a black rectangle, try launching from a terminal (below) or an X11 session on a different box to isolate compositor issues.

Confirm the helper and a compiler toolchain:

yay --version
pacman -Q base-devel

Step 1: Attempt the AUR install

Start by trying to install via the AUR as you normally would:

yay -S davinci-resolve

This will fail. Don’t worry, we just need the PKGBUILD to be downloaded.

Expected failure: yay clones https://aur.archlinux.org/davinci-resolve.git into ~/.cache/yay/davinci-resolve/ (paru uses ~/.cache/paru/clone/davinci-resolve/ — adjust later commands if you use paru). Then makepkg tries to fetch DaVinci_Resolve_*_Linux.zip and errors. Do not rm -rf that cache directory. The PKGBUILD and extra files are what we need.

ls ~/.cache/yay/davinci-resolve/PKGBUILD

If that path is missing, yay used a different cache. Find it:

find ~/.cache -name PKGBUILD | grep -i davinci

Step 2: Download the installer from Blackmagic

Head over to the Blackmagic Design support page and grab the Linux .zip file. You’ll need to fill out a quick form to download it.

Match the version to the PKGBUILD. Open the PKGBUILD and look at pkgver and the source= filename. If the AUR package is 21.0.4 and you download 21.1, makepkg will reject the zip on checksum or filename. Either download the version the PKGBUILD names, or bump pkgver/sha256sums yourself (only if you know how to makepkg and update checksums with updpkgsums). For this post we keep it simple: download the zip name the PKGBUILD already expects.

The filename I used when I wrote this down was DaVinci_Resolve_21.0.4_Linux.zip. Yours may differ. Do not unzip it. The PKGBUILD wants the zip.

Step 3: Move the zip into the AUR cache

Once downloaded, move the zip file next to the PKGBUILD that yay already pulled down:

mv ~/Downloads/DaVinci_Resolve_21.0.4_Linux.zip ~/.cache/yay/davinci-resolve/

The AUR build script expects the zip to be in that directory.

Why not leave it in Downloads? makepkg’s source directory is the cache clone. Files in ~/Downloads are invisible to the build unless you edit source= to a file:// URL. Moving (or copying) the zip is the least clever method and the one that survives yay’s next run.

Confirm names match exactly:

ls -l ~/.cache/yay/davinci-resolve/*.zip
grep -E 'pkgver|source=' ~/.cache/yay/davinci-resolve/PKGBUILD

Step 4: Retry the install

Run the same install command again:

yay -S davinci-resolve

This time it will find the zip locally and proceed with the build. Follow the prompts and you should be good to go.

Expected output: checksum verification, extraction, a long install into /opt/resolve, desktop files, maybe a prompt about skipping integrity checks if you touched the PKGBUILD. When it finishes:

ls /opt/resolve/bin/resolve
ls ~/.local/share/applications/DaVinciResolve.desktop /usr/share/applications/DaVinciResolve.desktop 2>/dev/null

Launch from the Omarchy/Hyprland launcher or:

/opt/resolve/bin/resolve

First start can be slow. Project Manager should appear. If the process exits instantly, skip to GPU sections — the install succeeded; the runtime did not.

That’s it (NVIDIA and Intel notes)

DaVinci Resolve should now be installed and available in your app launcher. If you run into issues with GPU acceleration, make sure you have the correct drivers installed for your hardware. Special thanks to Muflone in the AUR comments section for pointing this out.

On NVIDIA, the Arch workstation pattern still applies: proprietary driver, nvidia-smi healthy, and OpenCL:

sudo pacman -S opencl-nvidia
nvidia-smi

That is the same OpenCL package I use in the Arch NVIDIA + Resolve workstation guide. On Omarchy, if you needed nomodeset just to install the ISO, get a real driver in after install — Safe Graphics / nomodeset is only for the live environment.

On Intel iGPU boxes, Resolve on Linux is a lottery. I do not treat Intel as a supported edit GPU for this workflow. Use it to click around the UI at most.

AMD drivers (optional)

If you have an AMD GPU, install the ROCm OpenCL runtime:

sudo pacman -S rocm-opencl-runtime clinfo

clinfo should list a platform and a device. If it lists nothing, Resolve will not see a GPU. Reboot once after installing ROCm bits so the device nodes and groups settle. Your user typically needs to be in groups such as render and video:

groups
sudo usermod -aG render,video "$USER"

Log out and back in after usermod.

Test that Resolve launches:

HSA_OVERRIDE_GFX_VERSION=10.3.0 /opt/resolve/bin/resolve

Why HSA_OVERRIDE_GFX_VERSION? ROCm advertises a GFX IP version. Many RDNA cards that “should work” still need this override so the OpenCL stack pretends to be a supported target. 10.3.0 is the override that worked on the AMD box I tested; it is a compatibility knob, not a benchmark. If your card is a different generation, try without the variable first. If clinfo sees the GPU but Resolve still dies, then try the override. Do not invent other version strings from random comments if the stock launch already works.

If that works, make it permanent by editing ~/.local/share/applications/DaVinciResolve.desktop (copy from /usr/share/applications/ into ~/.local/share/applications/ if you need a user override) and setting the Exec line to:

Exec=env HSA_OVERRIDE_GFX_VERSION=10.3.0 /opt/resolve/bin/resolve %u

Then launch DaVinci Resolve from the menu — not from an old terminal that still has a different env — and you’re done.

Hyprland users: if the splash appears and the main window does not, try:

env QT_QPA_PLATFORM=xcb HSA_OVERRIDE_GFX_VERSION=10.3.0 /opt/resolve/bin/resolve

xcb forces XWayland. If that is the only way the UI appears, put QT_QPA_PLATFORM=xcb in the same Exec= line.

Linux Resolve still cannot eat phone H.264

Installing Resolve does not unlock the Windows-only decoder pack. Transcode to DNxHR the same way as on Mint:

sudo pacman -S ffmpeg
ffmpeg -i input.mp4 -c:v dnxhd -profile:v dnxhr_hq -pix_fmt yuv422p -c:a pcm_s16le output.mov

Details and a batch loop are in the Mint 21.3 guide. Same ffmpeg, different package manager.

Troubleshooting

  • yay rebuilds from scratch and fails again: the zip is not in the cache, or the filename does not match source=. Copy, do not rely on a browser that renamed it to DaVinci_Resolve_21.0.4_Linux.zip.zip.
  • Checksum mismatch: you downloaded a different patch level. Either get the exact zip or update sha256sums in the PKGBUILD with updpkgsums after placing the new zip.
  • /opt/resolve exists but launcher is missing: yay -S davinci-resolve may have been interrupted. Reinstall. Do not chmod random binaries as a substitute.
  • Audio devices missing: PipeWire vs Resolve’s ALSA/ASIO-ish expectations. Pick the correct audio device in Resolve preferences; on Omarchy, confirm PipeWire is the session default before blaming Blackmagic.
  • Project libraries on a network share: keep the database local. NFS/SMB project libraries on Linux Resolve are a support nightmare I do not recommend for a homelab editor.

Wrap-up

The Omarchy/Arch Resolve install is not “AUR is trash.” It is “the AUR is not allowed to host Blackmagic’s zip.” Drop the zip next to the PKGBUILD, rebuild, then fix OpenCL for your GPU. After that it is the same Linux Resolve you already knew from Mint or Rocky: transcode footage, respect the GPU driver, and do not expect Wayland to be as friendly as Windows.

For the rest of an Omarchy workstation (cursor theme, IDE tarball, ISO black-screen workaround), see Bibata on Omarchy, Antigravity on Arch, and Omarchy vs Windows 11.

Best regards,

The Linux IT Guy