davinci-resolve: Blackmagic Mini Panel hardware support not working

[lukego]

Describe the bug

The Blackmagic Mini Panel hardware device is not working with the davinci-resolve in nixpkgs.

I am troubleshooting this myself but I create this issue for sharing and visibility.

Steps To Reproduce

Method A:

1. Connect the panel via USB and enable in DaVinci Resolve -> Preferences -> Control Panels.
2. Restart DaVinci Resolve.
3. Panel does not connect to resolve and log contains the error below:

$ cat ~/.local/share/DaVinciResolve/logs/panel.log
opened log file
Opening communication to resolve..
Failed to create listener
Unsupported DaVinci Panel API Version (0.0), please update
Resolve discovery
Resolve discovery

Method B:

1. Connect the panel via Ethernet and enable in DaVinci Resolve -> Preferences -> Control Panels.
2. Restart DaVinci Resolve.
3. Panel does not connect and log contains a similar (but not identical) message:

$ cat ~/.local/share/DaVinciResolve/logs/panel.log
opened log file
Opening communication to resolve..
Failed to create listener
Unsupported DaVinci Panel API Version (0.0), please update

In both cases the display on the panel says "No Connection to DaVinci Resolve: Please go to DaVinci Resolve Preferences menu to select this panel." (This is the same behavior as powering on the panel with DaVinci Resolve is not running anywhere.)

Expected behavior

The panel should connect either via USB or via Ethernet.

Screenshots

Additional context

The same panel works out of the box with Resolve on macOS.

Notify maintainers

@jshcmpbll

Metadata

[luke@snowy:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.16.15, NixOS, 22.05 (Quokka), 22.05.git.19d4f7dc485`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.7.0`
 - nixpkgs: `/home/luke/git/nixpkgs`

[lukego]

This snippet from strace looks relevant (first and last lines):

[pid  9536] openat(AT_FDCWD, "/usr/lib64/libDaVinciPanelAPI.so", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid  9535] <... newfstatat resumed>{st_mode=S_IFDIR|0755, st_size=0, ...}, AT_EMPTY_PATH) = 0
[pid  9534] <... umask resumed>)        = 000
[pid  9524] <... msync resumed>)        = -1 ENOMEM (Cannot allocate memory)
[pid  9165] close(98 <unfinished ...>
[pid  8988] stat("/dev/random",  <unfinished ...>
[pid  9536] <... openat resumed>)       = -1 ENOENT (No such file or directory)

and find /nix/store -name libDaVinciPanelAPI.so does not find anything.

It's bedtime now but I suppose the next step is to locate this library.

[06kellyjac]

I've found it mentioned in a couple spots that look relevant

# Install panel API library
--
154 | create_directory ${DEB_DIR}/usr/lib/ | 154 | create_directory ${DEB_DIR}/usr/#LIBDIR#/
155 | extract_tgz ${UNPACK_DIR}/share/panels/dvpanel-framework-linux-x86_64.tgz ${DEB_DIR}/usr/lib/ libDaVinciPanelAPI.so | 155 | extract_tgz ${UNPACK_DIR}/share/panels/dvpanel-framework-linux-x86_64.tgz ${DEB_DIR}/usr/#LIBDIR#/ libDaVinciPanelAPI.so

https://bugs.gentoo.org/attachment.cgi?id=765724&action=diff#makeresolvedeb_1.5.1_multi.sh_sec1 (not sure where this makeresolvedeb_1.5.1_multi.sh file actually lives though)

Also mention of it here https://gist.github.com/Ashark/a194db36c8acd53f3cff496b617628fb

[lukego]

This seems to me like it should be the solution:

diff --git a/pkgs/applications/video/davinci-resolve/default.nix b/pkgs/applications/video/davinci-resolve/default.nix
index 5a3e76ffcaf..ca4f07d0165 100644
--- a/pkgs/applications/video/davinci-resolve/default.nix
+++ b/pkgs/applications/video/davinci-resolve/default.nix
@@ -108,7 +108,8 @@ let
         mkdir -p $out
         appimage-run ./DaVinci_Resolve_${version}_Linux.run -i -y -n -C $out

-        mkdir -p $out/{configs,DolbyVision,easyDCP,Fairlight,GPUCache,logs,Media,"Resolve Disk Database",.crashreport,.license,.LUT}
+        mkdir -p $out/{configs,DolbyVision,easyDCP,Fairlight,GPUCache,logs,Media,"Resolve Disk Database",.crashreport,.license,.LUT,libs/lib}
+        tar -zf $out/share/panels/dvpanel-framework-linux-x86_64.tgz -C $out/libs/lib -x
         runHook postInstall
       '';

but in practice it breaks the packaging by somehow preventing the usual binaries from being installed:

$ davinci-resolve 
/nix/store/kp8skhgi8wbisfnc2qr8hxq8g3mz3p8d-davinci-wrapper: line 3: /nix/store/bh2v86k2356vxprb9mp4rhwngbyk6xq6-davinci-resolve-17.4.3/bin/resolve: No such file or directory

and the reason for this is opaque to me.

[lukego]

This patch seems to make it find the panel library

diff --git a/pkgs/applications/video/davinci-resolve/default.nix b/pkgs/applications/video/davinci-resolve/default.nix
index 5a3e76ffcaf..1ae595f7bf6 100644
--- a/pkgs/applications/video/davinci-resolve/default.nix
+++ b/pkgs/applications/video/davinci-resolve/default.nix
@@ -160,6 +160,10 @@ buildFHSUserEnv {
     #python3
   ];

+  extraBuildCommands = ''
+    tar -zf ${davinci}/share/panels/dvpanel-framework-linux-x86_64.tgz -C $out/usr/lib64 -x
+  '';
+
   runScript = "${bash}/bin/bash ${
     writeText "davinci-wrapper"
     ''

... but then it fails to dynamically link libuuid.so.1. Seems to just not look in the right place. I've tried to nudge it with LD_LIRBARY_PATH but no luck. Weird?

Here's where it is looking:

[pid 163071] openat(AT_FDCWD, "/usr/lib64/lib/glibc-hwcaps/x86-64-v3/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/usr/lib64/lib/glibc-hwcaps/x86-64-v2/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/usr/lib64/lib/tls/x86_64/x86_64/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/usr/lib64/lib/tls/x86_64/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/usr/lib64/lib/tls/x86_64/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/usr/lib64/lib/tls/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/usr/lib64/lib/x86_64/x86_64/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/usr/lib64/lib/x86_64/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/usr/lib64/lib/x86_64/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/usr/lib64/lib/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/nix/store/hbvq1160w7k0k0cfpmpd1hn3gf6apika-glibc-2.34-115/lib/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/usr/lib64/lib/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 163071] openat(AT_FDCWD, "/nix/store/hbvq1160w7k0k0cfpmpd1hn3gf6apika-glibc-2.34-115/lib/libuuid.so.1", O_RDONLY|O_CLOEXEC <unfinished ...>

... but the path that should actually work is /usr/lib64/libuuid.so.1. There are a lot of other libraries in that directory too. I wonder what is the right place to make it look there?