Fix DaVinci Resolve installation (symbol lookup errors)

This post is mostly for my future self, but feel free to use the one-liner if you have just installed or upgraded BlackMagic DaVinci Resolve (Studio) onto your Linux machine and it’s not starting because of symbol lookup errors, e.g. /opt/resolve/bin/resolve: symbol lookup error: /usr/lib64/libpango-1.0.so.0: undefined symbol: g_string_free_and_steal.

One-liner

for lib in $(ldd /opt/resolve/bin/resolve | cut -d' ' -f1);
do
  [ -f "/usr/lib/${lib}" ] \
  && [ -f "/opt/resolve/libs/${lib}" ] \
  && { echo "Found ${lib} in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/${lib}" \
       && sudo rm "/opt/resolve/libs/${lib}"; } \
done

Example output

pn@vision ~ $ for lib in $(ldd /opt/resolve/bin/resolve | cut -d' ' -f1);
do
  [ -f "/usr/lib/${lib}" ] \
  && [ -f "/opt/resolve/libs/${lib}" ] \
  && { echo "Found ${lib} in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/${lib}" \
       && sudo rm "/opt/resolve/libs/${lib}"; } \
done
Found libavformat.so.60 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libavformat.so.60
Found libavcodec.so.60 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libavcodec.so.60
Found libavutil.so.58 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libavutil.so.58
Found libswscale.so.7 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libswscale.so.7
Found libmp3lame.so in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libmp3lame.so
Found libgstreamer-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstreamer-1.0.so.0
Found libgobject-2.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgobject-2.0.so.0
Found libglib-2.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libglib-2.0.so.0
Found libgstbase-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstbase-1.0.so.0
Found libgstapp-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstapp-1.0.so.0
Found libgstrtp-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstrtp-1.0.so.0
Found libgstvideo-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstvideo-1.0.so.0
Found libgstsdp-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstsdp-1.0.so.0
Found libgstpbutils-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstpbutils-1.0.so.0
Found libgstaudio-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstaudio-1.0.so.0
Found libgsttag-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgsttag-1.0.so.0
Found libgstwebrtc-1.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgstwebrtc-1.0.so.0
Found libgio-2.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgio-2.0.so.0
Found libgmodule-2.0.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/libgmodule-2.0.so.0
Found liborc-0.4.so.0 in both /usr/lib and /opt/resolve/libs - deleting /opt/resolve/libs/liborc-0.4.so.0

Explanation

  1. ldd is used to get a list of all shared libraries that the DaVinci Resolve executable (/opt/resolve/bin/resolve) links against
  2. The for loop iterates over these collected filenames and for each checks whether it’s both present in the standard library path (/usr/lib) and in DaVinci Resolve’s own libs directory (/opt/resolve/libs).
  3. If that is the case, they’re deleted from /opt/resolve/libs, so that only the ones coming with the distro remain.

Why does this work?

Some shared libraries (those that the one-liner deletes) that come with DaVinci Resolve are older versions that are not compatible with other libs that come with your distro.

At the time of writing there are 20 such libs, see in the Example Output section for a list.

By deleting them, the loader will find the ones in /usr/lib instead. These are compatible with the aforementioned other libs from your distro, because they are coming from your distro.

I’ve written the one-liner for DaVinci Resolve 19.1.2 and tested it with it on my Gentoo system. It should work on other distros as well.

Wayland, finally.

I’ve been watching the Wayland development from afar for a couple of years now, probably since 2014. But whenever I gave it a try, after less than 10 minutes something was so obviously broken that I immediately went back to X11.

Until yesterday, when I decided to give it another try. The trigger was, that KDE/Plasma felt sluggish on my machine. Even though it has decent specs (12 core Ryzen, Nvidia 4060 Ti, fast NVMe), opening a simple application like Konsole takes 1.5+ seconds. Even clicking the start menu button has a noticeable delay (~300-500ms). On X11 that is.

After rebuilding a bunch of packages (because I had to toggle the ‘wayland’ USE flag on, which had previously been off in my Gentoo installation), I chose the “Plasma (Wayland)” item in the SDDM dropdown and logged in. To my surprise KDE/Plasma instantly felt much better. No more delays, very smooth animations, etc.

IMO there must be serious bugs in Qt or KDE to have such bad performance on X11 nowadays. Using a simple Window Manager (Fluxbox) I didn’t feel any lags on X11. Even launching Konsole or other KDE apps from an xterm is snappy. But I don’t have the time and energy to do serious profiling, and I also really want to use KDE/Plasma.

So I’m happy that I didn’t find any issues with Wayland in the hours since. For a few minutes I thought screen recording was broken, but then it turned out that I just had to enable the ‘screencast’ USE flag and do a few rebuilds.

Will have to spend some time learning all the underlying concepts and new terms – but that doesn’t prevent me from using Wayland.

I’ll post updates here if / when I encounter issues.

Update (2025-01-05)

Today I wanted to write in German for the first time, and noticed that my .Xmodmap keyboard remapping for Umlauts no longer works. That was already problematic in X11 for a while, but it was a good solution that I’d been using for many years (and even “ported” to Windows – see here – when I had to use Windows at work).

So now I had to figure out something new. A guy in the always helpful German #gentoo-de@libera.chat IRC channel told me about the “EurKEY” keyboard layout – “The Layout for Europeans, Coders and Translators” – covers pretty much all European languages with one layout. Love it. And they took the exact same approach that I did: on an English keyboard, use a modifier key and when it’s pressed, “a” becomes “ä”, “o” becomes “ö” and so on. It comes out of the box in KDE, just had to choose it from the dropdown list!

The only issue with that is: they’re using the right ALT key as modifier, and I have nearly two decades worth of muscle memory using the Meta/Windows key as modifier. It would take a while to retrain myself, so I decided to instead remap the Meta/Windows key to the right ALT key. Works perfectly. Phew, problem solved.

Fix / workaround for non-linear volume control on Linux

Alright, it’s the time of the year where I find time to tinker a little. This time I wanted to find out why changing the volume didn’t feel “linear” for my beloved Teufel CONCEPT 8 2.1 sound system that’s connected to my PC via USB.

First of all I probably have to clarify what I mean by “didn’t feel linear”. I remember learning that human sound perception isn’t linear at all, so that’s probably not accurate. But what I mean here is that: When I slide the volume slider (or make discrete jumps via pactl set-sink-volume alsa_output.usb-NXP_SEMICONDUCTORS_Teufel_CONCEPT_8-00.analog-stereo 60%, for example), the loudest point is reached at already 40, maybe 45%, and after that it doesn’t get any louder. Or maybe it does? But if so, only marginally, and definitely not at the rate it does left of the 40% mark.

So I did some googling, but that turned up nothing specific to these speakers. And also nothing much helpful in general. I suspected some kind of quirk that nobody bothered adding a workaround for in the kernel so far. So I dove into the Linux kernel sources and tried a bunch of changes in sound/usb/mixer_quirks.c – e.g. setting cval->dbMin to different values for the USB ID of the Teufel CONCEPT 8, but also played around with cval->max as well as cval->res. It was rather tedious, because after every change I had to reboot, lacking the knowledge on how to test the changes “on the fly”. While I did observe changes to how the volume changed – e.g. the range where the volume changes fast shifted to the higher end – none of them yielded the results I wanted, i.e. “linear” volume change and no “dead zones” along the slider. So after a while I concluded that with my limited knowledge of the system’s inner workings, I could not understand how the numbers related to what I observed. So I wanted to learn more about the Linux USB audio subsystem, but gave up after a while because I figured that this would take up more time than I was willing to invest.

Just when I wanted to give up completely, I came across a bug report where someone recommended to choose the “Pro Audio” profile for the audio device instead of the “Analog Stereo Output” profile to get rid of this issue. And what can I say: works for me! The PipeWire FAQ states that using the “Pro Audio” profile “disables the hardware mixers, it only enables software volume/mute“. That’s probably what fixes the issue for me. I’d still love to understand why the issue exists in the first place though, and what the underlying layers are doing to mess up something seemingly simple as the volume slider. Maybe next Xmas holidays…?

See below a screenshot of the KDE System Settings / Sound. You can also use pavucontrol or its -qt variant to change the setting.