Troubleshooting – DisplayCAL https://displaycal.org Modern Python 3 Release for Windows 11 & macOS Sequoia. Powered by ArgyllCMS. Sat, 17 Oct 2026 08:55:43 +0000 en-US hourly 1 https://wordpress.org/?v=7.1.3 https://displaycal.org/wp-content/uploads/2026/04/favicon-150x150.png Troubleshooting – DisplayCAL https://displaycal.org 32 32 Fix “new_disprd failed” Error in DisplayCAL https://displaycal.org/displaycal-new-disprd-failed-fix/ https://displaycal.org/displaycal-new-disprd-failed-fix/#respond Sat, 17 Oct 2026 08:55:43 +0000 https://displaycal.org/displaycal-new-disprd-failed-fix/

Fix “new_disprd failed” Error in DisplayCAL

You click “Calibrate and profile”, the instrument initializes, and DisplayCAL aborts with an error mentioning new_disprd failed. This error comes from dispread, the ArgyllCMS tool DisplayCAL uses to take measurements. It means ArgyllCMS could not open a working communication channel to your colorimeter. The measurement never started, so your profiles and settings are not the problem. The driver and USB layer is.

The Troubleshooting Chain (In Order)

1. Check Device Manager (Windows)

Open Device Manager and look for your instrument. It should be under Argyll libusb-win32 devices. If it appears under the manufacturer’s name instead (X-Rite, Calibrite, Datacolor), the Argyll driver is not bound, and that is your problem. In DisplayCAL go to Tools, then Instrument, then Install ArgyllCMS instrument drivers, or run ArgyllCMS_install_USB.exe as administrator.

2. Change the USB Port and Cable

Unplug from any dock, hub, or monitor USB passthrough and connect directly to the computer. Try a different cable. USB signal issues manifest exactly like this error, and users report this step resolving it.

3. Reinstall the Argyll USB Driver with Zadig

If the bundled installer fails (Windows driver signature enforcement is the usual cause), use Zadig to manually set the instrument’s driver to libusb-win32. Steps are in our quickstart guide.

4. Reinstall ArgyllCMS Itself

A corrupted or mixed ArgyllCMS install (for example old DLLs next to new ones) can also break dispread. Remove the old ArgyllCMS folder completely, install current ArgyllCMS 3.5.0 fresh from our ArgyllCMS page, and point DisplayCAL at the new bin folder (File, then Locate ArgyllCMS executables).

5. One Instrument at a Time

Disconnect every other measurement device. Multiple instruments, especially similar models, can confuse driver binding (see also issue #304).

6. Linux: Permissions

On Linux this error usually means your user cannot open the USB device: join the plugdev group, install udev rules, reconnect. Details in our Linux guide.

Still Failing?

  • Isolate hardware vs software: test the meter in the vendor’s own app. Dead there means cable, port, or meter.
  • Read the full log. DisplayCAL’s log window shows dispread’s exact complaint. “Access denied”, “device not found”, and “open failed” point at different layers.
  • Ask with data. Open a GitHub issue with your OS, DisplayCAL version, ArgyllCMS version, instrument model, and the full error text.

How to Read the Error Log

DisplayCAL shows a log window during measurements. When dispread fails, scroll up and look for the lines just before the failure. Phrases mentioning access, permissions, or the device not being found point at the driver layer (steps 1 to 3 above). Mentions of missing files or wrong paths point at the ArgyllCMS installation itself (step 4). Copy the full error text when asking for help. A report that says “it does not work” without the log rarely gets a useful answer.

Preventing It Next Time

  • Keep one ArgyllCMS install. Problems often start when an old ArgyllCMS folder lingers next to a new one and DisplayCAL points at the wrong bin directory.
  • Do not let Windows Update replace the driver. After major Windows updates, check Device Manager. If the instrument moved out of the Argyll device group, reinstall the Argyll driver.
  • Label your working port. If one USB port works reliably, keep using it. USB controller quirks differ per port.

Quick Checklist Before You Start Over

Before reinstalling anything, run through this sixty-second checklist: is the meter firmly plugged into a rear motherboard USB port, is any other measurement software closed, does Device Manager show the instrument under the Argyll group, and is DisplayCAL pointed at the correct ArgyllCMS bin folder? Users report that a surprising share of “new_disprd failed” cases are resolved by one of these four checks, no reinstall needed.

Related: DisplayCAL troubleshooting hub | Instrument not detected: 8 fixes | Quickstart guide

Frequently Asked Questions

What does ‘new_disprd failed’ mean?
It is an error from ArgyllCMS’s dispread tool (which DisplayCAL drives) indicating it could not open communication with the measurement instrument. It is a driver and USB layer failure, not a bad profile.
I reinstalled everything and it still fails. What next?
Test the instrument in the manufacturer’s own software. If it fails there too, suspect the cable, USB port, or the instrument itself. If it works there, the problem is the Argyll driver binding. Try Zadig to force libusb-win32.
Does this happen on macOS or Linux?
The error is most commonly reported on Windows, where the USB driver binding is the fragile step. On Linux it usually means a permissions problem; on macOS, a cable or hub problem.
Should I downgrade ArgyllCMS?
No, upgrade instead. Current ArgyllCMS is 3.5.0 with the newest driver packages. Downgrading reintroduces old bugs.

]]> https://displaycal.org/displaycal-new-disprd-failed-fix/feed/ 0 DisplayCAL on Wayland: What Works and What Doesn’t https://displaycal.org/displaycal-wayland-guide/ https://displaycal.org/displaycal-wayland-guide/#respond Sat, 17 Oct 2026 08:55:34 +0000 https://displaycal.org/displaycal-wayland-guide/

DisplayCAL on Wayland: What Works and What Doesn’t

Running Linux with Wayland and wondering why DisplayCAL behaves strangely? You are not alone. GitHub issue #133 (“wayland no access to video card gamma table”) has been open since 2022 and explains the fundamental limitation.

The Core Problem

DisplayCAL’s calibration step loads correction curves into the video card gamma table (the GPU LUT). Under X11, applications can do this freely. Under Wayland, the compositor does not expose gamma table access to applications. This is a deliberate design decision. No application, DisplayCAL included, can work around it from user space.

What Works Under Wayland

  • Profiling. Measuring the display and building an ICC profile works fine. The instrument, the patches, and the math do not need the gamma table.
  • Profile installation via colord. colord is the color management daemon that GNOME and KDE use. DisplayCAL can hand it your profile and color-managed apps will use it correctly.
  • Verification reports. Measuring and reporting on your display works normally.
  • Interactive display adjustment. As of 3.9.18, the previously reported hang of the interactive adjustment step under Wayland is fixed. Upgrade if you hit it.

What Does NOT Work

  • Loading calibration curves into the GPU (the “calibration” part of “calibrate and profile”). The video LUT simply cannot be written under Wayland.
  • The profile loader applying vcgt corrections at login, for the same reason.

Recommended Workflows

Option A. Profile-only under Wayland (simplest)

  1. Use your monitor’s on-screen controls to get close to your target first: set brightness, RGB gains for white point (D65), and gamma preset.
  2. In DisplayCAL, run a profile-only workflow (skip the calibration stage).
  3. Install the profile. Color-managed applications (GIMP, Krita, Firefox with color management) will display correctly.
Why this is fine: as discussed in issue #133, on a decent display the calibration-stage adjustments are tiny. Profiling alone gives color-managed apps exactly the same result. You only lose the cosmetic improvement for unmanaged apps.

Option B. Calibrate under X11, use under Wayland

  1. At the login screen, choose an Xorg / X11 session instead of Wayland.
  2. Run the full DisplayCAL calibration and profiling workflow there.
  3. Save the profile. You can then use the ICC profile back under Wayland (the GPU LUT part will not apply there, but the profile characterization remains valid).

Things to Disable Before Measuring

Night-light and blue-filter features quietly shift your white point and will corrupt measurements. Turn them off. This applies on every platform, but Wayland desktops love enabling them by default.

Still Having Trouble?

How to Check Whether You Are on Wayland

Open a terminal and run:

echo $XDG_SESSION_TYPE

If it prints wayland, the limitations on this page apply to you. If it prints x11, you have full gamma table access and can ignore this page. Most distributions let you pick the session type on the login screen via a gear or cog icon.

A Note on Expectations

It is worth being clear about what you give up under Wayland: only the video LUT calibration stage. Everything else DisplayCAL does, measuring, profiling, verification, 3D LUT generation for video software, works the same. For photography and design work in color-managed applications, a profile-only workflow under Wayland is a complete solution, not a compromise. The X11 session is only needed if you specifically want GPU-level calibration curves loaded, for example to make unmanaged applications look right.

Related: DisplayCAL troubleshooting hub | DisplayCAL on Linux | Quickstart guide

Frequently Asked Questions

Can DisplayCAL calibrate a display under Wayland at all?
Profiling (creating the ICC profile) works. What does not work is loading corrections into the video card gamma table, because Wayland does not expose that API to applications. For full calibration including the video LUT, use an X11/Xorg session.
Do I need to switch to X11 permanently?
No. Many users profile under X11 and use the resulting profile under Wayland, or simply do a profile-only workflow under Wayland and adjust the monitor’s on-screen controls for white point and brightness.
What is colord and do I need it?
colord is the system color management daemon on Linux that hands ICC profiles to the desktop (GNOME and KDE support it). DisplayCAL can install profiles for colord to use. That part works under Wayland.
Was the Wayland hang fixed?
DisplayCAL-py3 3.9.18 fixed the interactive display adjustment step hanging under Wayland. If you are on an older version, upgrade before troubleshooting further.

]]> https://displaycal.org/displaycal-wayland-guide/feed/ 0 DisplayCAL Not Detecting Colorimeter? 8 Fixes That Work https://displaycal.org/displaycal-instrument-not-detected/ https://displaycal.org/displaycal-instrument-not-detected/#respond Sat, 17 Oct 2026 08:55:25 +0000 https://displaycal.org/displaycal-instrument-not-detected/

DisplayCAL Not Detecting Your Colorimeter? 8 Fixes

DisplayCAL shows “no instrument detected” even though your colorimeter is plugged in. Before you assume the hardware is dead, work through these fixes. They come from real user reports, including GitHub issue #304, where an i1 Display Plus HL was invisible to the software.

Fix 1. Install the ArgyllCMS Instrument Drivers (Windows)

DisplayCAL needs Argyll’s USB driver, not the manufacturer’s. In DisplayCAL go to Tools, then Instrument, then Install ArgyllCMS instrument drivers. Alternatively, run ArgyllCMS_install_USB.exe as administrator from the Argyll_V3.5.0\usb folder. Then check Device Manager: your instrument should appear under Argyll libusb-win32 devices.

Fix 2. Use Zadig if the Install Fails

If the driver installation fails (often due to Windows driver signature enforcement), use Zadig to manually replace the instrument’s driver with libusb-win32. This is the standard fallback documented in our quickstart guide.

Fix 3. Plug Directly Into the Computer

The issue #304 reporter made a point of connecting directly to the computer’s USB port rather than through a USB-C docking station. Docks and hubs are a frequent source of detection failures. Also try a different cable and a different port.

Fix 4. Check ArgyllCMS.inf for Your Instrument (Advanced)

This is an advanced, user-reported fix from issue #304. Editing driver files can break driver installation. Back up the file first, and only try this if the standard install does not list your instrument.

In the issue, the Argyll USB driver package had the reporter’s instrument commented out in ArgyllCMS.inf:

;"Eye-One Display 3 (Argyll)" = LIBUSB0_DEV, USB\VID_0765&PID_5020

The reporter uncommented the three Eye-One Display 3 entries (32-bit and 64-bit sections), re-ran the installer, and both instruments appeared. If your instrument is a rebranded i1 Display Pro variant (Calibrite, NEC SpectraSensor, HP DreamColor), it may share the same VID/PID (0765:5020) and be affected the same way. Note: newer ArgyllCMS 3.5.0 driver packages may already include these entries, so upgrading ArgyllCMS is the safer first try.

Fix 5. One Instrument at a Time

Issue #304’s title mentions problems appearing after inserting a third instrument. If you have multiple meters connected, unplug all but one and test. VID/PID conflicts between similar devices are a known source of confusion.

Fix 6. Linux: Check USB Permissions

On Linux, your user must be able to access the USB device. Add yourself to the plugdev group and make sure the udev rules for the instrument are installed, then unplug and reconnect. See our Linux guide.

Fix 7. macOS: Check Permissions and the Cable

On macOS there is no driver to install. Detection failures are usually the cable, a hub, or (on newer macOS) a permission prompt you dismissed. See our macOS guide.

Fix 8. Confirm the Instrument Works Elsewhere

Test the colorimeter with the manufacturer’s own software (Calibrite Profiler, Spyder software). If it is not detected there either, the problem is hardware, cable, or USB, not DisplayCAL.

Still Not Working?

  • Run DisplayCAL’s instrument detection with logging and look for USB errors. Paste them into issue #304 or open a new issue.
  • Try our troubleshooting hub for related fixes.

Related: DisplayCAL troubleshooting hub | Quickstart guide | Fix “new_disprd failed” error

Frequently Asked Questions

Why does DisplayCAL see my colorimeter but ArgyllCMS tools do not (or vice versa)?
DisplayCAL talks to instruments through ArgyllCMS drivers. If the OS-level USB driver is the manufacturer’s instead of Argyll’s libusb driver, Argyll tools, and therefore DisplayCAL, cannot open the device. This is the most common cause.
Do I need to disable driver signature enforcement on Windows 11?
The reporter in issue #304 did disable it as a prerequisite for installing the Argyll USB driver. Whether you need it depends on your Windows configuration. Try the normal install first.
My instrument worked in DisplayCAL 3.8.9.3 but not in the py3 branch. Why?
In issue #304, the older version recognized the instruments while the newer Argyll USB driver package did not list them. The cause was commented-out entries in ArgyllCMS.inf. Newer ArgyllCMS versions (3.5.0) have updated driver packages, so upgrading may resolve it.
Can I use a USB hub or docking station?
Users report mixed results. The issue #304 reporter connected directly to the computer’s USB port rather than through a dock as a troubleshooting step. Direct connection is the safest test.

]]> https://displaycal.org/displaycal-instrument-not-detected/feed/ 0 DisplayCAL White Point Wrong? 6500K Measures as 6400K https://displaycal.org/displaycal-white-point-wrong/ https://displaycal.org/displaycal-white-point-wrong/#respond Sat, 17 Oct 2026 08:55:16 +0000 https://displaycal.org/displaycal-white-point-wrong/

DisplayCAL White Point Wrong? 6500K Measures as 6400K

You set the white point target to 6500K (D65). You run the calibration. The measurement report comes back: 6400K, for both target and result. You try “as measured”, you try manual 6500K, you re-measure. Still 6400K. This exact behavior was reported in GitHub issue #411.

The Reported Case

The reporter was creating a Video 3D LUT for DaVinci Resolve (not an ICC profile) on a BenQ EW3270U connected through an UltraStudio Monitor 3G to a MacBook Pro, using DisplayCAL-py3 3.9.13 with ArgyllCMS 3.3. Key detail: with the older 3.9.12, the same monitor calibrated to about 6500K without trouble, so something in the 3D LUT workflow settings was off, not the panel.

First: Rule Out the Usual Suspects

  • Warm-up. Measure only after the display has been on for 30+ minutes. A cold panel drifts.
  • Ambient light. Changing room light between setting the target and measuring shifts readings.
  • Wrong correction (CCSS). If your colorimeter uses a spectral correction for the wrong panel type, white point readings skew. See our CCSS guide.
  • Observer mismatch. ArgyllCMS 3.4+ renamed the CIE 2012 observers to CIE 2015. Stale observer settings can shift results slightly.

The Fix That Worked (Community-Reported Settings)

Attribution: these settings were reported by community member Adam-Color in issue #411 after hours of trial and error. They are user-reported, not official guidance, but they produced a correct white point where the defaults did not.
  1. In DaVinci Resolve: use video levels.
  2. In DisplayCAL: use full levels all the way through.
  3. Turn drift compensation off.
  4. Set black level to as measured.
  5. Set tone curve to as measured. (The reporter noted tone curve calibration appears broken in this workflow.)
  6. Set black output offset to 100%.
  7. Use absolute gamma.
  8. Set rendering intent to preserve saturation.
  9. Turn apply calibration (vcgt) on.

With these settings, the reporter got a solid calibration result with the proper white point. The maintainer acknowledged the 3D LUT workflow may have a bug in 3.9.x and said it was worth investigating.

If the Numbers Are Close but Not Exact

A white point landing within a few dozen kelvin of target is often measurement variation, not failure. Instruments, panel drift, and observer math all contribute. What matters is the verification report: if it shows the target was hit within tolerance, the calibration did its job. For the visible match between two displays, DisplayCAL’s alternate white point editor lets you nudge the white point until the screens look identical to your eyes, useful when two panels measure the same but look different.

Still Not Working?

  • Update everything. The issue thread suggests upgrading to the latest DisplayCAL, Python, and ArgyllCMS. The reporter’s older 3.9.12 behaved correctly, so a regression is possible.
  • Try the ICC profile workflow as a control test: if a normal display profile hits 6500K but the Resolve 3D LUT path does not, the problem is isolated to the 3D LUT settings.
  • Check our Resolve 3D LUT settings guide for the full recommended configuration.
  • Report it. Add your display model, connection chain, and versions to issue #411.

Related: DisplayCAL troubleshooting hub | Quickstart guide | How to read your verification report

Frequently Asked Questions

Why does my 6500K target measure as 6400K?
In the reported case (GitHub issue #411), the white point read 6400K in the measurement report no matter what target was set, specifically in the Video 3D LUT for Resolve workflow. A community member’s settings (video levels in Resolve, full levels in DisplayCAL, drift compensation off) resolved it for them.
Is a 100K white point error visible?
A 100K deviation around D65 is small and usually not visible in isolation, but it indicates the calibration did not hit its target. Worth fixing because it suggests a settings mismatch rather than a real panel limitation.
Should I use the ‘as measured’ white point?
If your panel cannot physically reach the target, ‘as measured’ avoids fighting the display. But if the panel can reach 6500K and the report still shows 6400K, the problem is in the workflow settings, not the panel.
Does the observer setting affect white point?
Yes. Different standard observers compute slightly different white points from the same measurement. ArgyllCMS 3.4+ renamed the CIE 2012 observers to CIE 2015; mismatched observer settings can shift readings.

]]> https://displaycal.org/displaycal-white-point-wrong/feed/ 0 DisplayCAL Profile Not Applied After Reboot (macOS Fix) https://displaycal.org/displaycal-profile-not-applied-after-reboot/ https://displaycal.org/displaycal-profile-not-applied-after-reboot/#respond Sat, 17 Oct 2026 08:55:07 +0000 https://displaycal.org/displaycal-profile-not-applied-after-reboot/

DisplayCAL Profile Not Applied After Reboot (macOS Fix)

You calibrate your display, the profile applies perfectly, then you log out, reboot, log back in, and your calibration is gone. The screen looks uncalibrated again. This is a real, confirmed bug in DisplayCAL-py3 on macOS, reported as GitHub issue #392.

Symptoms

The pattern from the issue report is very specific:

  • You run a calibration in DisplayCAL and apply it to the current user. It works.
  • You log out of macOS (or restart the Mac) and log back in.
  • The profile is no longer applied. The display looks as if it was never calibrated.
  • Re-applying manually in DisplayCAL works again, until the next logout.

Reported environment: macOS Sonoma 14.6.1, DisplayCAL-py3 3.9.12 installed from the wheel, Python 3.11, ArgyllCMS 3.1.0. If your setup matches, this page is for you.

Why It Happens

DisplayCAL applies calibration in two parts: the ICC profile (characterization data) and the video LUT (the correction loaded into the graphics card, sometimes called vcgt). The profile file stays on disk, but the video LUT lives in the GPU and is wiped on logout and reboot. Something has to reload it at every login, normally DisplayCAL’s profile loader. On macOS, the loader does not reliably start at login for some users, so the LUT is never restored.

Fix: Re-Apply the Profile Automatically at Login

Attribution: the steps below are the workaround reported by a user in issue #392, not an official fix. It uses ArgyllCMS’s own dispwin tool, the same program DisplayCAL uses internally to load profiles.

Step 1. Find your profile and dispwin

Locate your saved .icc profile (check ~/Library/Application Support/DisplayCAL/storage/) and your ArgyllCMS bin folder (check ~/Library/Application Support/DisplayCAL/dl/).

Step 2. Create the reload script

Create a file such as ~/bin/display_profile.sh with this content, replacing the paths with your own:

#!/bin/sh
"/Users/YOURNAME/Library/Application Support/DisplayCAL/dl/Argyll_V3.5.0/bin/dispwin" -v -d1 -I "/Users/YOURNAME/Library/Application Support/DisplayCAL/storage/YOUR-PROFILE.icc"

Make it executable:

chmod +x ~/bin/display_profile.sh

Step 3. Create a LaunchAgent

Create ~/Library/LaunchAgents/com.displaycal.profile.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.displaycal.profile</string>
    <key>Program</key>
    <string>/Users/YOURNAME/bin/display_profile.sh</string>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Step 4. Load it and test

launchctl load ~/Library/LaunchAgents/com.displaycal.profile.plist

Now log out and back in. Your calibration should be applied automatically.

Still Not Working?

  • Check the script runs manually first. Run ~/bin/display_profile.sh in Terminal. If dispwin reports an error, fix the paths before blaming launchd.
  • Verify the profile itself is valid. Re-run a verification report after manually applying. A corrupt profile will not load no matter how you trigger it.
  • Try DisplayCAL’s own loader. Check the profile loader and autostart options in DisplayCAL. For some users the built-in loader works once re-enabled.
  • Upgrade ArgyllCMS. The issue was reported with ArgyllCMS 3.1.0; current is 3.5.0. This may help but is not a confirmed fix for this issue.
  • Follow the issue. Add your environment details to issue #392 so the maintainer can reproduce it.

Related: DisplayCAL troubleshooting hub | Quickstart guide | Profile loader guide

Frequently Asked Questions

Why does DisplayCAL apply the profile fine but lose it after reboot?
DisplayCAL’s profile loader runs in your user session. On macOS, if the loader does not start automatically at login, or the system resets the display state, the calibration (video LUT) is not re-applied. This is the exact behavior reported in GitHub issue #392.
Is the launchd workaround safe?
It runs ArgyllCMS’s own dispwin tool with your saved profile, the same operation DisplayCAL performs when you install a profile. It was reported by a user in issue #392 and worked for them. Keep a backup of your .icc file before trying.
Does this affect Windows or Linux?
This specific report is macOS-only. On Windows, use DisplayCAL’s profile loader autostart option; on Linux, display managers typically restore the profile via colord.
Will upgrading DisplayCAL fix it?
Issue #392 was reported against 3.9.12 and is still open. Upgrading to 3.9.19 is still worthwhile for other macOS fixes, but do not assume it resolves this. Test after upgrading.

]]> https://displaycal.org/displaycal-profile-not-applied-after-reboot/feed/ 0