[argyllcms] Re: More on instrument access
- From: "Hal V. Engel" <hvengel@xxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sun, 6 Jan 2008 16:31:50 -0800
It appears to me that this is somewhat distro specific and may also depend on
the versions of the various bits of software on the system. On my machine
the EyeOne Display Lt just worked (don't ask me why) and I didn't need to do
anything related to udev or hotplug. But I did need to setup a udev rule to
get the Spyder2 to work. I am not sure why this is the case. For me on my
Gentoo system the following udev rule worked:
# Spyder 2
SYSFS{idVendor}=="085C", SYSFS{idProduct}=="0200", PROGRAM="/bin/sh -c 'K=%k;
K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c",
MODE="660", GROUP="usb"
The only difference between this and what is in the ArgyllCMS docs is the
group used (IE. usb instead of plugdev). This is with kernel 2.6.22 and udev
115.
On Sunday 06 January 2008 14:04:31 Leonard Evens wrote:
> I've been spending an enormous amount of time trying to figure out how
> to get access to an instrument as a user other than root. In the
> process I've learned quite a lot about udev rules, how to create them
> and how to test them, which I suppose will eventually be of use. In the
> process, I believe I've found a bug in the way udev works with my latest
> Fedora kernel
> kernel-2.6.23.12-52.fc7
>
> But, after trying all sorts of complicated things, I did finally find
> something which works. The argyll web page suggests that for the latest
> versions of udev, something like the following should work.
>
> # i1Display
> SYSFS{idVendor}=="0971", SYSFS{idProduct}=="2003", GROUP="plugdev"
>
> That certainly won't work for me since I don't have a group "plugdev".
> But I tried it with a group I do have and belong to, and it did change
> the group ownership of the device but left the permissions at 0644 which
> didn't do me any good.
>
> So I tried
>
> # i1Display
> SYSFS{idVendor}=="0971", SYSFS{idProduct}=="2003", MODE:="0666"
>
> instead, and much to my amazement, this did work. In my case the device
> is /dev/bus/usb/004/xxx. Here 'xxx' is a positive integer given as three
> digits possibly starting with leading zero(s). It is incremented by one
> each time I plug in the device and a new instance is created, the
> previous instance having disappeared. The ':=' is an instruction to
> preserve the assignment even if later rules try to change it. I think
> just using '=' for the assignment won't work because I've tried similar
> things in the past, but I haven't actually tested that. "004" refers to
> the particular usb port I always use, and I presume it would work
> similarly if I chose another port. So wherever the device is plugged
> in, every user should have access to it with the argyll programs.
>
> Perhaps the web page should be altered to reflect what I've outlined
> here. Of course, given apparent problems with the current kernel and
> udev, I can't be sure this will survive the next kernal upgrade, but I
> have hopes.
>
> One of the strange things I found is the following. The argylll web
> page suggests as an earlier approach the rule
>
> SYSFS{idVendor}=="0971", SYSFS{idProduct}=="2003", PROGRAM="/bin/sh -c
> 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*}
> $${K#*.}'", NAME="%c", MODE="666"
>
> This actually sets the permissions properly on the device, although the
> PROGRAM statement returns with error status 1, in which case the NAME
> assignment is not made. That is because %k has the value 4-1 and the
> shell syntax results in something printf can't parse. udevtest seems to
> tell me in this case that the device is created with mode 0644. The net
> result of using this rule is that the permissions are set properly but
> how the fragment of the rule MODE="666" remaining after PROGRAM and
> NAME are ignored, is implemented is entirely unclear.
Other related posts:
