Overcoming missing DisplayCAL dependacies on recent Linux distros with X11 container

DisplayCAL has been a great free tool to partner your hardware colour calibrator, like your DataColor Spyder etc. However installing this on any of the newer mid-2020 distributions (like Fedora 32 and above) has become problematic due to the python 2 requirements being dropped by a number of distributions.

How can we continue to use your DataColor Spyder with DisplayCAL on a recent linux?

The last known working version of DisplayCAL on Fedora was for F31 so there are 2 options:

• live boot media (USB/DVD) of F31 and manaully install depedancies for DisplayCAL
• run DisplayCAL from a F31 container on your current workstation

I'll only cover the latter option above since its the apparently easier option, particularly since the calibration measurement can take around 90-100 minutes, you can run the DisplayCAL container on your monitor whilst doing something useful on your host.

Using docker or podman we can to create an image as normal but the only complications is that we require the X11 subsystem and we will rely on some of the systemd like services.

Dockerfile and build

The following will give us the build configuration and build us an image tagged as f31-displaycal

$ cat > Dockerfile << EOF FROM fedora:31 RUN dnf install -y libXScrnSaver libXdmcp https://displaycal.net/download/Fedora_31/x86_64/DisplayCAL.rpm dbus-x11 && dnf clean all CMD [ "/sbin/init" ] EOF $ podman build -t f31-displaycal .

This will provide ArgyllCMS 1.9.2 and DisplayCAL 3.8.9.3 in an 525MB docker image. Whilst DisplayCAL, on startup, will advise and try to install newer versions of ArgyllCMS I've found that this can be hit and miss.

If you wish to run a ArgyllCMS 2.1.2 (this also requires the libXdmcp package) you can download manually, make availabe on a shared volume mount and request DispalyCAL to locate the binaries.

Running the DisplayCALX11 container

This is where its a little tricky as we need a service enabled before we can start DisplayCAL

$ mkdir -p ${HOME}/.local/share/DisplayCAL # start a container named 'displaycal' for ease of referencing later # add '-it' to the command below if you want to see what is happening (not a lot) # on the terminal, otherwise the container will run in the background # can use 'podman -f displaycal' to check the log $ podman run --name displaycal --rm \ -u 0 -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix:rw \ --device /dev/bus/usb/:/dev/bus/usb --net=host \ -v $HOME/.local/share/DisplayCAL:/root/.local/share/DisplayCAL \ f31-displaycal # attach to running container to launch 'dispalyCAL' tool $ podman exec -t -i displaycal bash systemctl start dbus displaycal

The --device ensures that the container can see the USB colour calibration device and the volume mounts on /tmp/.X11 will allow the container to reach the localhost's X display. Finally, the volume mount of .local/share/DisplayCAL will provide an easy way for you to retreive your generated .icc profile as this is the location used within the container and mapped to your locahost.

Whilst DisplayCAL is running, remember to disable screensavers and monitor power saving to ensure the calibration tool can continue to measure correctly.

Remember, once the container is stopped the data generated will be lost so you must have a way to get the generated .icc out of the container -- of course we can also install scp but this is not necessary as we have shared the local $HOME/.local/share/DisplayCAL with container where the container will have written the profiling information. Once DisplayCAL is complete, quit out of that and then stop the main running container: podman stop displaycal.

Now with this, we can perform the calibration and pick up the generated .icc and import it into color etc.

Profiling and .icc

From the initial screen ensure the Mode is set correct for your monitor type (backlight WLED,CCFL etc) which can be verified here. The default calibration settings (under Profiling on the main display page) aims to produce a high quality profile but at the expense of time. This can be affected by:

• profile quality - high vs medium
• test chart - auto optimised/adjustable number of patches vs specific test charts/fixed number of patches

The difference between high (~95mins) vs medium (~55mins) with auto optimised is noticable.


Once the profile is generated, it will have an embedded description which typically is the monitor name, date and the test coverage. I have seen that sometimes on multi monitor setups the monitor name is not always correct - this results in an .icc that declares itself as something different which can be very confusing. If you need to modify the generated .icc, you can use IccXML to convert to an XML, update the ascii description before reencoding back to an .icc.