I took your suggestion and installed 15.0b3. All went well with just the message about Resolve requiring the the ligCg.and libCgGL version info.

The splash screen and project manager screens open perfectly in the centre of the screen, but the main screen is off centre and cant be re-positioned. All the basics of the edit module seem to work, create bins, import media, timeline etc, but there are no minimize/maximize buttons. I have installed from a clean Ubuntu install a number of times.

I'm not a Linux expert, and I'm a Resolver beginner, so I could be missing something obvious. I have read back on the topic and tried most of the previous suggestions.

Sometimes I have the slight feeling that I should change to some other software, since I bought Licenses for DaVinci and Fusion its always a "waiting and hoping" to get some bugs fixed.They are kind of experimenting too much instead of going for stability.

it would be also nice if they would tell their customers about their roadmap and goals.

That's a little odd. I actually get the same reference even from a working system and there is no styles-directory included in the installer so that is probably normal.

Looks like the most useful informational log message after that and before before SIGILL (illegal instruction) is "Updating display GPU information...". I suspect that something goes wrong when Resolve is gathering information about the GPU situation. This may be a driver and/or library issue.

Do you have multiple GPU:s installed in your system? Such as a built in Intel Iris together with the Nvidia. If that is the case, try to disable/remove that other non-Nvidia GPU and uninstall any proprietary driver.

What versions of the Nvidia packages do you have installed? (dpkg -l | grep nvidia) Do you perhaps have mixed packages from different Nvidia driver versions?

Have you ever run any official Nvidia installer on this machine? (it's nasty)

Having audio support in v15 is great. But how can I see the audio waveform in the timeline?

I have a mp3 file that I had to convert to wav in order to get Davinci to "see" it in Media Manager. I have waveform there. But when I drag it to an Audio Track on my Timeline, I have no waveform there. Any clues how to get it displayed?

If I double click on the track, I have the waveform loaded in the 1st preview box. But I prefer to have it in my timeline, to be able to align video transitions by it.

EDIT: Never mind, I had to poke for 15 minutes and not find it, then post here and I found it 3 clicks later It was under the "Timeline View Options" button -> "Audio Waveforms" button...

That's a little odd. I actually get the same reference even from a working system and there is no styles-directory included in the installer so that is probably normal.

I was wondering what happens next to the one i mentioned. What next few calls are, so i can guess where the problem could be. It's hard to debug using strace for me anyways, just running out of ideas by now. I am still unable to launch resolve, so can't see it by myself.

Daniel Tufvesson wrote:Looks like the most useful informational log message after that and before before SIGILL (illegal instruction) is "Updating display GPU information...". I suspect that something goes wrong when Resolve is gathering information about the GPU situation. This may be a driver and/or library issue.

Do you have multiple GPU:s installed in your system? Such as a built in Intel Iris together with the Nvidia. If that is the case, try to disable/remove that other non-Nvidia GPU and uninstall any proprietary driver.

Agree, but i'm using 390.48 packaged for ubuntu, NVIDIA installer wasn't ever used on this setup. I have a standard 1060 6gb board, nothing special about it (flashing, overclocking, voltmod, etc). Just one GPU, and nothing onboard, don't really see anything of importance. Phenom X6 16gb of DDR3 ram ./makeresolvedeb_15.0b3-1.sh lite gives 0 errors. Resolve on win runs fine...

Daniel Tufvesson wrote:What versions of the Nvidia packages do you have installed? (dpkg -l | grep nvidia) Do you perhaps have mixed packages from different Nvidia driver versions?

Only nvidia-settings is still 390.42 for some reason. Is an ubuntu update thing, this is not the issue as you'll be able to see further

More attempts to get 15 beta working:

NVIDIA-Linux-x86_64-396.18.run and no cuda - same thingNVIDIA-Linux-x86_64-396.18.run and cuda-repo-ubuntu1710-9-2-local_9.2.88-1_amd64.deb + cuda-repo-ubuntu1710-9-2-local-cublas-update-1_1.0-1_amd64.deb - the samecuda_9.2.88_396.26_linux.run (this one comes with drivers, so i removed everything) - same thingSuddenly 14.3 works with your makeresolvedeb_14.3-2.sh Daniel. It's useless for me, as i only have onboard audio, but i can't get what the difference could be (14.3 vs 15.x).

I can reinstall ubuntu, try with debian again...maybe with centos it would work

aidanryan wrote:I removed pocl.icd from /etc/OpenCL/vendors which had no effect. I also tried to remove mesa-libOpenCL, which was not installed. I then installed mesa-libOpenCL and removed all .icd files from /etc/OpenCL except nvidia.icd. This proved to be what allowed Resolve 15b3 to run on my particular Fedora 27 installation. It seems that OpenCL must be present on the machine, even if you intend to run Resolve using CUDA.

Sulo Kokki wrote:From the Beta forum, corroborating what's been suspected for a while.

aidanryan wrote:I removed pocl.icd from /etc/OpenCL/vendors which had no effect. I also tried to remove mesa-libOpenCL, which was not installed. I then installed mesa-libOpenCL and removed all .icd files from /etc/OpenCL except nvidia.icd. This proved to be what allowed Resolve 15b3 to run on my particular Fedora 27 installation. It seems that OpenCL must be present on the machine, even if you intend to run Resolve using CUDA.

BMD should fix it already.

I only have mesa.icd and nvidia.icd in that folder, moving mesa.icd away has no effect.The package mesa-opencl-icd is installed, removing it has no effect.

Sulo Kokki wrote:From the Beta forum, corroborating what's been suspected for a while.

aidanryan wrote:I removed pocl.icd from /etc/OpenCL/vendors which had no effect. I also tried to remove mesa-libOpenCL, which was not installed. I then installed mesa-libOpenCL and removed all .icd files from /etc/OpenCL except nvidia.icd. This proved to be what allowed Resolve 15b3 to run on my particular Fedora 27 installation. It seems that OpenCL must be present on the machine, even if you intend to run Resolve using CUDA.

BMD should fix it already.

I only have mesa.icd and nvidia.icd in that folder, moving mesa.icd away has no effect.The package mesa-opencl-icd is installed, removing it has no effect.

I think we may be on to something here. I was able to replicate this problem on my Debian 9 install by removing the package nvidia-opencl-icd. Installing nvidia-opencl-icd made Resolve happy again.

Daniel Tufvesson wrote:I think we may be on to something here. I was able to replicate this problem on my Debian 9 install by removing the package nvidia-opencl-icd. Installing nvidia-opencl-icd made Resolve happy again.

I have a similar experience with Linux Mint 18. After installing CUDA, Resolve failed to run. ocl-icd-opencl-dev got it started - on CUDA, as well.

Getting identical message on Ubuntu 16.04, no nvidia card (using an old radeon 5450 - don't laugh, i just want to try it on a xeon cpu).

installed manually from DaVinci_Resolve_15.0b3_Linux.sh with md5 cad9b9a4c989ce1eed15fbae2308927d (i also looked at the deb creation script but chose to do all steps manually). installation complained about missing /usr/lib64 which is missing in Ubuntu. will investigate when I have more time what exactly is trying to do/copy there.

Marc, you’ve installed both the driver and the CUDA package? On Linux you should only need the driver as CUDA support is included inside the driver. Also, I don’t trust 290.56+ (I’m still on 390.48) as 396 is a ‘major’ revision designed to support CUDA 9.2 and 390.56 refuses to function for me. Try downgrading to 390.48 and see if that helps. I’m also running CentOS so YMMV. I’ll take a stab at B4 if I get a chance today.

Using GPU on the Fusion page probably shouldn’t be recommended yet unless they’ve made some serious improvements to the OpenCL implementation.

I think he made a Freudian slip and used the DOS command instead of mkdir. More on the matter:

Daniel Tufvesson wrote:My main concern here is the libDaVinciPanelAPI.so library which I'm not sure how it's used. My guess is that bmdpaneld or DaVinciPanelDaemon uses it somehow but it does not show up as a linked library using ldd. If we are unlucky, that file must still be placed in the /usr/lib64 path. I don't have a panel so I can not test this and I'm actually not very keen on buying one until I know it works.

Aside that, you really use makeresolvedeb.

Daniel Tufvesson wrote:Regarding system wide libraries affected by Resolve, there isn't that many really. The only libraries that are installed into the system library path /usr/lib64 by the original installer are the dvpanel libraries. All other libraries are installed into /opt/resolve/libs or /opt/resolve/bin. The dvpanel library package also contain avahi, libc++, libusb and libdns if I remember correctly. This may be okay for CentOS/RH but is not something I want to just copy into the system library path on another Linux distro such as Debian or Ubuntu. My script instead places these libraries into the /opt/resolve/bin directory to avoid corrupting the OS. Anyone running Debian or Ubuntu along with a panel and managed to get it working?

Unfortunately I did not get a chance to test. Won’t get a chance to until this weekend. I would recommend trying the following:

Try installing on a fresh machine (regardless of version). Use the deb package. Install 390.48 (The official install PDF uses 390.42, but 48 is safe). Do not install the CUDA SDK package. See if that gets things working.

What's the current status of Resolve 14.3 on Ubuntu 16.04?Is there a list of what's working, what's not, and how to install?

I'm working to get Resolve on a few computers in a community Makerspace. Installed using the steps in the official Readme that came with the Linux download, but Resolve won't launch - it just flashes in the taskbar for a bit before vanishing. I'm trying to figure out whether it's worth my time trying to get it working on Linux, or whether I should nuke the machines and try to find the funding to get Windows for them.

that's at least the way, how i bridge the gap by help of nvidia-docker sandboxes on my debian testing system. it's just another experimental approach, but i will definitely do less harm do your existing environment than BMDs installer or questionable quick and dirty hacks.

+1---I think we should be extremely grateful to blackmagicdesign for the free resolve and the very low priced resolve studio package!As a part time developer I'm deeply impressed by the ver 15 four betas, how much they've added and fixed in each one and how much of that directly covers 'complaints' and wishes on the forum!!!

I now have an iMac 5k, an older MacBook Pro i7/nvidia, a linux Ubuntu Studio/Intel Xeon and a linux Ubuntu Studio/Amd Threadripper with fully (? working 15b4 !!!

The linux part thanks to Daniel Tufvesson and his fantastic service to the community who want's linux but not Centos right now I've been trying Centos with several versions also before v15, but with newer HW issues and some other problems, why bother? - at work I 'only' use linux redhat and some centos but not for video, only still images etc, and other people maintain them...

I really look forward to the resolve 15 stable, I think it will be a benchmark for the competition (who ever that is and a fantastic resource for video production!---Some of the complaints on the forum are of course users in delivery stress with something they want to work on a platform that they have'nt tested enough before they use it in real production!

Some other complaints I see as unfair to the tremendous work blackmagicdesign has done since I started to follow Resolve---Keep up the good work!And the forum is fantastic in it's generousity

Martin Schitter wrote:there is perhaps another possibility to work around this stupid boycott of the most widely used linux distributions

You should really work on your attitude. That's not a 'stupid boycott' but an economic decision from BMD. I guess you never ran you own business.

it's more than implausible, to interpret this stubbornness as a reasonable 'economic decision', because the actual market share of the excluded popular distributions is in fact many times higher than CentOS installations in real world use!

they would also only have to change/adapt a few lines of code in the installer script resp. minimal efforts, and everything would work at least as compatible to this other distributions as we are able to archive it now by very uncomfortable workarounds resp. unnecessary manual interventions.

so it's really more a kind of attitude on BMDs side, which can hardly be euphemized as something, which doesn't seem like 'pure ignorance' to all affected linux users.

Sure MartinI think I was as irritated as you were when the linux resolve before 15 didn't use system audio and required BM HW, and I had problems to get their HW to work both on macos and linux

Of course blackmagicdesign have to choose where they use their developing resources

Users who do grading on linux resolve (which I think is a very important customer group) are probably not doing the mix down of all sound tracks...---We all look forward to 'all' features work as fast/faster than the competion an all three platforms with v15And the improvements are so fast nowadays

bjornzitting wrote:Of course blackmagicdesign have to choose where they use their developing resources...

yes -- i really feel a lot of sympathy for all this pragmatic needs to set priorities, and i'm really glad, that they began to support linux at all in more accessible manner, but the mentioned necessary changes are so incredible trivial and were already reported/suggested so many times by affected users, that i really do not see an excuse, why we didn't see the slightest improvement in this regard since the first beta release of resolve for linux (i.e. more than 15 months!).

When we talk linux the first I think about is stability and performance!!!No hidden communication from OS to Cupertino, Seattle or wherever...---I can understand why BM develop on one HW platform on one linux distribution they trust and understand to get 'all' resolves features to deliver close to 100% CPU and GPU whenever possible before adding other HW/distributions complexityThis could be done in a 'closed room' without telling us they even ARE ON LINUX!---I like the openness of public beta and in some rare cases NDA before that (been there...)Stupid hidden developments that miss their target when delivered due to bad real world connection is typical (in my view) of bigger corporations on the stock market - not from open source projects

BM is an interesting subject here- Not open source - Not attempting to introduce their own (off) standards, have I missed it? - Happy to publish public betas- Not really showing their roadmap (?) but really fast to execute it - And very responsive to the forum

I see BM as a very modern player understanding the 'industry' needs and latest tech

I've now got resolve running quite well on Ubuntu 18.04. My testing is very basic as I'm a real Resolve beginner, but so far so good.If my problem has already been answered before, forgive me. I only get audio from AVCHD .mts files, no video. The media shows "Offline" in the Media pool and Timeline. Mp4 files do nothing. DVCPro mxf are fine.

Mts and mp4 work fine on my Resolve Windows instalation, but I desperately want to get away from windows.

Any suggestions would be appreciated.

Also wondering if its possible to buy an unlock key when the final version 15 Studio is released. Could I then just unlock the downloaded installation, or are there any extras in the boxed version. I believe the dongle is being phased out.

I'm glad you got it working Neil! I actually think you need the Studio version in order to get those files to read properly. The file and codec support is a lot better.

The good thing is that you used my MakeResolveDeb tool. That way, when you buy a Studio license, all you have to do is make a new Resolve Studio *.deb file and replace your existing davinci-resolve package with the davinci-resolve-studio package. Your Resolve installation will be converted to a Resolve Studio installation with settings and database intact!

It doesn't matter if you get a dongle or a key. The software is the same and what you get in the box is the same as on the website.

Thanks Daniel, your help in making your deb packages available is really appreciated. Thanks also to all the other members who share their knowledge here. Also to Black Magic for supplying such great software for absolutely no charge.

I was along time user of Premier Pro, until they went the subscription route, and then I changed to Edius Pro. They are both good as well, but there is something special about Resolve. And now it’s on Linux!! I gotta have it.

Martin Schitter wrote:it's more than implausible, to interpret this stubbornness as a reasonable 'economic decision', because the actual market share of the excluded popular distributions is in fact many times higher than CentOS installations in real world use!

Bear with me, but the stubbornness seems to come from your side. CentOS support is a 'byproduct' from having RHEL support in the first place. RHEL is supported because paying customers do want enterprise distributions that come with support contracts most of the time. People who don't want to get a RHEL entitlement, still have the option of using CentOS. As it's pretty much the same to RHEL bitwise, there is no additional effort needed for BMD to support this combo. So that's apples and oranges, when you compare the market share of CentOS to other "community" or "desktop" linux derivates.

linuxfreak wrote:... the stubbornness seems to come from your side....RHEL is supported because paying customers do want enterprise distributions that come with support contracts most of the time. ... So that's apples and oranges, when you compare the market share of CentOS to other "community" or "desktop" linux derivates.

come on! -- just look at some real world numbers instead of arguing in a quite speculative manner:

if you study this kind of statistics/trends, it should look more than obvious, that those days, where RHEL/CentOS undoubtedly represented a significant option, are more or less bygone history! RHEL plays a nearly negligible role at the present day.

but even, if it isn't a very popular choice anymore, i don't see any necessity to ignore or discriminate against this particular choice. if linux software is written with care, it simply should run on any kind of distribution with minimal adaptation efforts.

it's somehow a hybrid solution, where you really use an unmodified CentOS resolve installation resp. runtime environment within an arbitrary linux host ambient. in this case, all of the CentOS specific dependencies and library versions are handled within the container in a perfectly reproducible and consistent manner. this makes it much easier, to reduce incompatibilities, trace actual bug reports and reduces the amount of necessary external installation requirements. the surrounding container hosting environment just provides the necessary general infrastructure in very compatible way. it should be better seen in analogy to running CentOS on various kinds of actual hardware.

especially resolves demand of CUDA access doesn't make it easy to realize this kind of environment isolation in practice, but the developers of nvidia-docker already prepared a fantastic solution, to work around all this nividia related dependencies and driver version incompatibilities in very satisfaying and mature manner. in the meanwhile it has become the de facto standard solution for CUDA acceleration in cloud related tasks (e.g. machine learning jobs running on kubernetes clusters...).

all the necessary tools to realize this kind of solution are already available for nearly any kind of linux distribution and well maintained by nvidias development team. o.k. -- it's a little more tricky on alpine and clear linux, but on the more common choices, its acceptable easy to install nvidia-docker, although not utterly trivial.

nevertheless i still have my doubts, if it's really an acceptable solution to the given problem or if daniels approach, to simply repack .deb packages, isn't a more satisfaying solution for the affected actual debian/ubuntu/mint users?

in fact, it would be very easy for me, to add this kind of debian repacking into the actual CI solution, just the same as it's now generating the docker images automatically. i often use this kind of private debian packaging and deployment via aptly based private repositories hosted on GitLab pages in my inhouse work as well. it's a really nice and user friendly solution, to provide all the necessary update requirements in very comfortable and debian-like manner, but in this particular case, i don't think, it would be adequate.

i simply do not see any reliable way, to test and avoid all the possible incompatibilities in a sufficient manner in the given case. simple repacking of complex binary applications should be IMHO only seen as the last resort, if no other passable alternative is available. it can not substitute proper adaption and CI handled compilation/generation of perfect fitting packages for the most relevant target platforms/distributions. that's why i have precautionary chosen this other approach in this particular case, which undoubtedly also has it's drawbacks and uncomfortable/frightening complexity, but it seems to provide at least a little bit more control and robustness concerning all the mentioned well know obstacles and show stoppers.

bjornzitting wrote:I can understand why BM develop on one HW platform on one linux distribution they trust and understand to get 'all' resolves features to deliver close to 100% CPU and GPU whenever possible before adding other HW/distributions complexity

If only.

The Linux port is still rinky-dink. They use CentOS out of convenience, as Resolve ran originally on RHEL. There's a host of questionable solutions, many inherited by BMD from the DavSys base. Opening the port beyond the turnkey system has exposed these shortcomings and it looks less than pretty.

For sure, the software and the port are welcome, but that hardly excuses all the issues that come with it. BMD's been lax in fixing the issues that have been reported many times over, so this convo is a bit Groundhog Day. We keep hoping for (more) fixes on every release and keep pointing issues out, because a more wholesome Linux port is better for all.

A point can be made that Resolve is usable on Linux, but at the same time, the current port is barely sufficient.

Yes SuloFrom the developers viewpoint it's much easier to target one 'linux' HW/Distribution and attempt to get same functionality as on MacOS/Windows Then open up to more distributions/more HW varieties

From a user perspective, only CentOS packaged by BM and only HW recommended by BM might workBut I and many others want other combinations HW/distributions - like Ubuntu...---I agree the current gigantic shell script to install Resolve on CentOS is a 'beta hack' since it doesn't even support uninstallThis should be extremely easy for BM to change - still on CentOS platform ---To open up to 'all' linux distributions on diverse powerful HW combinations is of course more complicated, but something we all expect from a non-beta professional softwareMy guess is we have a fully reliable resolve on high-end linux platforms long before Christmas

After b3 removal and b4 clean install, I've got persistent Segmentation Fault after Resolve start on my Ubuntu 16.04 with GTX1070. After dancing with strace and logs, I've installed Cuda developer package as described here https://developer.nvidia.com/cuda-downl ... rch=x86_64 . Now I can start Resolve with no problem. May be someone find this info helpful.