"new_disprd() failed with 'Instrument Access Failed" Linux, again

[Florian Höch]

I have no experience with AppArmor. If you really need it, it probably needs to be configured appropriately for your needs.

[Herve5]

I have no experience with AppArmor. If you really need it, it probably needs to be configured appropriately for your needs.

I don’t say I need it or not, I am just searching for anything that may limit accesses. On the other hand, I’m totally unable to remove or edit AppArmor (I think there isn’t even a GUI it seems); I don’t want to trash my system just trying things…

I am back to my main question : why doesn’t DisplayCAL have the right write accesses to the USB device, and why the origina method, at the top of this post, does not work for me. The guy wasn’t on Debian,  so the commands on Debian may not be the same?

[Herve5]

A quick precision : the “original method at the top of this post” is Dominig’s, here

What fails is that at the end, I don’t get updated acls…

[Herve5]

So, here is what I did today :

• I plugged the i1studio on an usb port and noted where it appeared in the DisplayCAL log : on /dev/bus/usb/001/013
• I checked once more that nobody had write access to this, with

:~$ sudo getfacl /dev/bus/usb/001/*

(...)

# file: dev/bus/usb/001/013
# owner: root
# group: root
user::rw-
group::rw-
other::r--

• I then added the group ‘colord’ with write access, with

~$ sudo setfacl -m g:colord:rw /dev/bus/usb/001/013

I checked the rights again :

~$ sudo getfacl /dev/bus/usb/001/*

(...)

# file: dev/bus/usb/001/013
# owner: root
# group: root
user::rw-
group::rw-
group:colord:rw-
mask::rw-
other::r--

• I then started DisplayCAL, which now seems to behave properly. At least, I was able to launch a calibration and see the whole process starting.

My question : will this setup maintain itself if for instance I reboot the machine, or do I have to redo all of this each time I want to use DisplayCAL?

Thank you!

• This reply was modified 5 years ago by Herve5.
• This reply was modified 5 years ago by Herve5.
• This reply was modified 5 years ago by Herve5.
• This reply was modified 5 years ago by Herve5.
• This reply was modified 5 years ago by Herve5.

Calibrite ColorChecker Studio on Amazon  
Disclosure: As an Amazon Associate I earn from qualifying purchases.

[Florian Höch]

My question : will this setup maintain itself if for instance I reboot the machine, or do I have to redo all of this each time I want to use DisplayCAL?

I do not know. You’ll have to try and see.

[Herve5]

So, the setup is not maintained, as a couple of days after when I replug the i1Studio it now registers on a different USB port allocation (/dev/bus/usb/001/014 instead of /dev/bus/usb/001/013) and I have to re-issue the complete setfacl command (keeping in mind the previous one has open an ACL for nothing on the previous port 13)

I dearly understand Dominig’s approach when he apparently creates a rule that will declare the right ACL only, and specifically, to the right instrument, connected to the right port. But I am too novice in Debian Linux commands to be able to adjust it for myself. Could you help there?

[Florian Höch]

Well, the point of the udev rules is that you shouldn’t have to do anything manually to set up device permissions.

Check your ColorMunki device ID with lsusb in a terminal. Post the output. It will be something like this:

Bus 001 Device 001:  ID XXXX:XXXX Vendor name/device info
Bus 002 Device 002:  ID XXXX:XXXX Vendor name/device info

The XXXX:XXXX are the hex vendor and device ID. Compare this to the ColorMunki entry in the udev rules (55-Argyll.rules, idVendor and idProduct).

[Herve5]

I get vendor = 0765 and product ID = 6008 :

~$ lsusb
(...)
Bus 001 Device 002: ID 8087:0a2b Intel Corp.
Bus 001 Device 017: ID 0765:6008 X-Rite, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Now, when reading /etc/udev/rules.d/55-Argyll.rules and ‘jumping’ from a ‘vendor 0765’ to the next ‘vendor 0765’, to my surprise I see :

(...)
# ColorMunki Smile
ATTRS{idVendor}=="0765", ATTRS{idProduct}=="6003", ENV{COLORD_SENSOR_KIND}="color-munki-smile", ENV{COLORD_SENSOR_CAPS}="lcd-ccfl lcd-white-led"

# ColorMunki i1 Studio
ATTRS{idVendor}=="0768", ATTRS{idProduct}=="6008", ENV{COLORD_SENSOR_KIND}="color-munki-photo" ENV{COLORD_SENSOR_CAPS}="lcd crt projector printer spot ambient"

# DTP20
ATTRS{idVendor}=="0765", ATTRS{idProduct}=="d020", ENV{COLORD_SENSOR_KIND}="dtp20" ENV{COLORD_SENSOR_CAPS}="printer spot"
(...)

I tried to turn it bold here, but clearly, the only place where product ID 6008 appears, it is associated… to another vendor ID, and there is just no couple “0765” “6008” anywhere in  this file.

I now have edited it and changed the 0768 into 0765, just to see, the I issued ~$ sudo udevadm trigger in the idea that this would reload the udev rules (is this OK?).

But then when I launch DisplayCAL, again I have the infamous

Setting up the instrument
20:00:36,738 usb_open_port: open '/dev/bus/usb/001/017' config 1 failed (-1) (Permissions ?)
20:00:36,745 usb_open_port: open '/dev/bus/usb/001/017' config 1 failed (-1) (Permissions ?)
20:00:36,746 dispread: Error - new_disprd failed with 'Instrument Access Failed'

and when checking ACLs I get:

~$ getfacl /dev/bus/usb/001/*
(...)
# file: dev/bus/usb/001/017
# owner: root
# group: root
user::rw-
group::rw-
other::r--

In other words no mention of group colord apparently?

• This reply was modified 4 years, 12 months ago by Herve5.

[Florian Höch]

So, there we have it, this device is unknown to udev because the udev rules seem to have a typo in the vendor ID. Change it from 0768 to 0765 [ that typo is easy to make for a technical person, as 768 is one of the many numbers that are a multiple of two that are very common in computer graphics 🙂 ]

[Florian Höch]

Remember to unplug and replug the i1 Studio.

[Herve5]

Remember to unplug and replug the i1 Studio.

Oh God -yes, in effect, I DID forget, and now it works!!

Thanks for the enormous support!!

[Author]

Posts