#20051 (Bug) DisplayCAL 3.8.6 hangs on random patch a few minutes into calibration

+1 0

Closed as Fixed
Component: DisplayCAL 3.8.6 | Milestone: 3.8.7
Created by btspce

Last modified

I have never had any trouble with DisplayCAL until upgrading to 3.8.6 and last successful time I did a calibration was on 3.8.0.

Calibration goes on for about 5-10 minutes and then I get multiple “dispcal: inverting Jacobian failed (3) – falling back”. A few minutes later it seems to stops/hang s on a random patch colour and I have to cancel the calibration as nothing happens and time left only goes up and up. You can still cancel the calibration at this point.
Tested on both Internal laptop screen and external LCD and both fails with multiple “dispcal: inverting Jacobian failed (3) – falling back” and then stops/hangs
X-rite i1 Display is tested with the I1Profiler software and works on Windows 10 without any problems.

X-rite i1 Display
DisplayCAL 3.8.6
Fedora 30 x64

Can I download 3.8.0 again somewhere so I can restest ?

displaycal_logs (application/zip | 2019-09-10 16:42:14)
displaycal_logs_jacobian (application/zip | 2019-09-10 16:42:14)

5 comments on “DisplayCAL 3.8.6 hangs on random patch a few minutes into calibration”

  1. When in doubt, try under X instead of Wayland. Wayland support was added in 3.8.1, 3.8.0 doesn’t work under Wayland at all. Under Wayland, you have to make sure that nothing moves in front of the measurement window.

  2. I retested and made sure nothing moved in front of the calibration window. (All other programs closed and left the computer) hanged/got stuck on black patch 2 of 64 right after the first 9.
    Also connected a USB2 hub between laptop and i1 Display in case of the usb issue but that didn’t help either.

    Anything else I could try?

  4. Switched to X and ran two calibrations without problems. Thanks for the fast support Florian !

  5. Looking through your logs some more, it appears the problem is latency under Wayland – if the measurement window is large, generating a dithered pattern image can take hundreds of milliseconds, which Argyll’s display update delay can’t account for because it measures the needed delay from black to white difference (no dithering there with full range RGB).

    I’ve committed a change to SVN which now explicitly waits for the generated image to be displayed (revision 6206), if you want to try that.

Comments are closed.