#20751 (Bug) Error-new_disprd failed with ‘instrument Access Failed’

+1 0

New
Component: DisplayCAL
Created by Josh4783

Last modified


this is the error i keep getting…..          Error-new_disprd failed with ‘instrument Access Failed’

please help me fix this i am running windows 10,9900k 2080ti  and i1 display by x-rite


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).

  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

    [[email protected] ~]$ 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?

  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.

  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.

    Incorrect naming odf functional device.

    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.

Leave a Reply