7.2 Linux 37
7.2.2.4 For udev on Ubuntu 06.10
Edit the file /etc/udev/rules.d/40-permissions.rules. Search for the entry for usbfs. It should look like this:
# USB devices (usbfs replacement)
SUBSYSTEM="usb_device" MODE="0664"
Now change it to read like this:
# USB devices (usbfs replacement)
SUBSYSTEM="usb_device" GROUP="plugdev", MODE="0664"
7.2.2.5 udev on some other systems
Some very up-to-date systems also set the environment variable $USB_DEVFS_PATH to point to "/dev/bus/usb"
instead of the older (default) value of "/proc/bus/usb". This may cause the mvBlueFOX libraries to attempt
to access device nodes in "dev/bus/usb" but the rules described above will not change the permissions on
these files. Normally you will find a rule in "/etc/udev/rules.d/50-udev.rules" which will already cure
this problem. You might like to slightly modify this rule to give write permission to a specific group e.g. the group
"usb". A patch is supplied in the scripts directory to do this.
7.2.2.6 Alternatively, for a system with full hotplugging (e.g. older SuSE systems)
Copy the files named below from the scripts directory into the directory "/etc/hotplug/usb":
matrixvision.usermap
matrixvision_config
The file "matrixvision.usermap" contains the vendor and product IDs for the mvBlueFOX cameras and
specifies that the script "matrixvision_config" should be run when a MATRIX VISION mvBluefOX cam-
era is plugged in or out. This script attempts to write some information to the system log and then changes the
permissions for the newly-created device node so that non-root users can access the camera.
This feature has not yet been extensively tested. If you find that the applications start but appear to hang or to wait
for a long time before continuing (and normally crashing) then changing the file permissions on your system does
not appear to be sufficient. We have observed this on a 32 bit SuSE 9.1 system. In this case you may have more
success if you change the owner of the application to "root" and set the suid bit to allow it to run with "root"
permissions.
Note
This is considered a security risk by some experts.
If you have been using the mvBlueFOX with one user (e.g. root) and want to try it as another user you should
remove the complete directory "/tmp/mv/", which may contain several files of zero length. These files are
used to control mutexes within the software and will be owned by the first user. The new user will probably not
be able to write to these files and the mvBlueFOX will not work.
7.2.2.6.1 Using CMOS versions of the mvBlueFOX and mvBlueFOX-M especially with USB 1.1
Version 1.4.5 contains initial support for CMOS mvBlueFOX on USB 1.1 . In order to conform to the rigid timing
specifications of the CMOS sensor, onboard RAM is used. This RAM is available only on mvBlueFOX-M boards at
the moment. Therefore you cannot use the mvBlueFOX-102x with USB 1.1 . It will work with USB 2.0.
Note
If you want to capture continuous live images from mvBlueFOX-102 or mvBlueFOX-M102x you should switch
the trigger mode from "Continuous" to "OnDemand" for best reliable results. For single snaps the default
values should work correctly.
MATRIX VISION GmbH
To Next Page
Loading...
