DisplayCAL

7 comments on “Error-new_disprd failed with ‘instrument Access Failed’”

1. “i1 display by x-rite”

   There are several different devices under that brand. Which one is it? If it is not the i1 Display Pro, you need to install the ArgyllCMS driver for it (see QuickStart guide in documentation).

   Log in to Reply

2. I’ve spent a bit of time trying to track down the cause of this system on my own PC.  I have a Thinkpad P50, which has a built-in Pantone colorimiter, which is connected into the internal USB hub of the laptop.

   Bus 001 Device 016: ID 0765:5010 X-Rite, Inc.

   I also have a Pantone Huey colorimeter hooked up via USB.

   Bus 001 Device 023: ID 0971:2005 Gretag-Macbeth AG Huey

   WHen attempting to calibrate, here is the debug output.

   14:59:58,817 Session log: 0_16
   14:59:58,817
   14:59:58,818 Working directory:
   14:59:58,818   /
   14:59:58,818    tmp/
   14:59:58,819     DisplayCAL-OSaxvs/
   14:59:58,819
   14:59:58,819 Command line:
   14:59:58,819   /usr/bin/dispread
   14:59:58,820     -v
   14:59:58,820     -D8
   14:59:58,820     -k
   14:59:58,821     /usr/share/DisplayCAL/linear.cal
   14:59:58,821     -d1
   14:59:58,821     -c2
   14:59:58,822     -yl
   14:59:58,822     -P0.501386321627,0.817193675889,1.57142857143
   14:59:58,822     0_16

   … elided spew …

   5:00:03,799 icoms_refresh_paths: we now have 2 devices and are about to sort them
   15:00:03,800 icompaths_make_dslists '/dev/bus/usb/001/023 (GretagMacbeth Huey)' dctype      ↲
   ↳ 0x10002
   15:00:03,800 icompaths_make_dslists '/dev/bus/usb/001/016 (GretagMacbeth Huey)' dctype      ↲
   ↳ 0x10002
   15:00:03,800 icoms_refresh_paths: returning 2 paths and ICOM_OK
   15:00:03,800 Number of patches = 3
   15:00:03,800 Setting up the instrument
   15:00:03,801 new_inst: called with path '/dev/bus/usb/001/016 (GretagMacbeth Huey)' type    ↲
   ↳ 'Huey'
   15:00:03,801 new_icoms '/dev/bus/usb/001/016 (GretagMacbeth Huey)' itype 'Huey' dctype      ↲
   ↳ 0x10002
   15:00:03,801 icom_copy_path_to_icom '/dev/bus/usb/001/016 (GretagMacbeth Huey)' returning   ↲
   ↳ dctype 0x10002
   15:00:03,801 huey_init_coms: About to init coms
   15:00:03,802 huey_init_coms: About to init USB
   15:00:03,802 icoms_set_usb_port: About to set usb port characteristics
   15:00:03,802 usb_open_port: Make sure USB port is open, tries 0
   15:00:03,802 usb_open_port: About to open USB port '/dev/bus/usb/001/016'
   15:00:03,855 usb_open_port: open port '/dev/bus/usb/001/016' succeeded
   15:00:03,855 usb_open_port: Claiming USB port '/dev/bus/usb/001/016' interface 0 initally   ↲
   ↳ failed with -1
   15:00:03,856 usb_open_port: Claiming USB port '/dev/bus/usb/001/016' interface 0 failed     ↲
   ↳ with -1
   15:00:03,857 usb_open_port: Claiming USB port '/dev/bus/usb/001/016' interface 0 failed     ↲
   ↳ with -1
   15:00:03,857 huey_init_coms: set_usb_port failed ICOM err 0x20000
   15:00:03,857 init_coms returned 'Communications failure' (Communications failure)
   15:00:03,857 new_disprd failed because init_coms failed
   15:00:03,858 icoms_del: called
   15:00:03,861 dispread: Error - new_disprd failed with 'Instrument Access Failed'
   15:00:03,864
   15:00:03,866 DisplayCAL: Reached EOF (OK)
   15:00:03,972 ...aborted.
   

   We can see that dispread is choking on the presence of the unsupported colorimiter, although there is indeed a second supported colorimeter hooked up to the system.

   I have attempted to disable the internal colorimeter using a udev rule in /etc/udev/rules.d/01-disable-unsupported-colorimeter.rules

   [chrism@thinkm ~]$ cat /etc/udev/rules.d/01-disable-internal-colorimeter.rules
   ACTION=="add", ATTR{idVendor}=="0765", ATTR{idProduct}=="5010", RUN="/bin/sh -c 'echo 0 >/sys/\$devpath/authorized'"
   

   This has no effect, or at least if it has an effect it is not to cause dispread to ignore the device.

   I think dispread just needs to attempt to continue if it finds an unsupported device.  Maybe I could supply a patch.  I checked quickly but could not find the version control for the source online, any hints?

   Log in to Reply

3. We can see that dispread is choking on the presence of the unsupported colorimiter, although there is indeed a second supported colorimeter hooked up to the system.

   It certainly doesn’t fail during enumeration, but because you have the device selected and are thus trying to use it. Simply select the other, presumably working device. Also, make sure it is not a permissions problem by installing the latest Argyll udev rules.

   I checked quickly but could not find the version control for the source online, any hints?

   ArgyllCMS is not in public VCS. You can download the current development snapshot from the official website.

   Log in to Reply

4. It certainly doesn’t fail during enumeration, but because you have the device selected and are thus trying to use it. Simply select the other, presumably working device.

   You’re right, of course.  I chose the other listed device and it worked.

   However, there appears to be another bug that lists the working device as a ColorHug instead of a Huey, thus my confusion.  I thought of it as the class of instrument rather than the instrument itself, as a result.

   

   Adding to my confusion I actually *do* have a ColorHug, it’s just not plugged in right now.

   I’ll see if I can figure out why it is misidentifying the instrument as a ColorHug.

   Log in to Reply

5. Note that under Windows, the sensors are both reported as “Huey” (which makes sense, because the internal colorimeter is a HueyL, albeit unspported).

   

   Log in to Reply

6. You need to click the “refresh” button on the main tab when you have unplugged or attached a new device.

   Log in to Reply

7. You need to click the “refresh” button on the main tab when you have unplugged or attached a new device.

   Thanks.  Clearly I’m not smart enough to use this software.

   Log in to Reply