[argyllcms] Re: More on instrument access
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Mon, 07 Jan 2008 13:21:55 +1100
Leonard Evens wrote:
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.
This is what's mean to happen. I'd imagine one of the other
udev rules has the "printf bus/usb/%%03i/%%03i" code in
it to create the device.
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.
It's hard to know. All the stuff already there is supposed to have
worked for at least one person. I'm not sure how useful it is
to keep expanding it with more untested information. Unless someone
is very persistent, they are more likely to give up and simply run
it as root.
[I can't actually follow the logic of why Linux by default is
setting unknown USB devices to user read only. It is the
cause of all these issues. If the system doesn't know about
a device, then there will be no tools that come with
the system that can access it, so to set permissions so
that no user added tool can access it, means that it is
completely inaccessible! ]
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.
I don't understand why that is. I couldn't actually test this
stuff myself (since my Linux system uses hotplug rather than
udev, and hotplug is considerably easier to tame), but I did try
the shell program at one stage, and it seemed to work, and this is
copied directly from other suggestions of what works - see
<http://forums.gentoo.org/viewtopic-t-459308-highlight-camera+root.html?sid=a322727f7ea0a94aafd84fd0e13604ef>
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.
I really don't know what do about Linux and device permissions. It's simply
a big mess that makes Linux very unfriendly to casual users.
Graeme Gill.
Other related posts:
