Thread: [libdc] point grey chameleon
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
From: Aryeh W. <ar...@cc...> - 2013-07-08 18:41:47
|
I am trying to get a point grey chameleon to work under Suse 12.3 using libdc1394 + libusb. I see from the archives that this has been done, but my camera is not being recognized with by micromanager or by any of the examples provided with libdc1394. lsusb detects the camera and prints its USB info, and the camera function correctly udner Win7, so the camera is not broken. Can anyone tell me what I am missing? Thanks in advance --aryeh -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 |
From: Rodolphe P. <pi...@rt...> - 2013-07-10 16:32:52
|
On Mon 7/8/13, at 11:34, Aryeh Weiss <ar...@cc...> wrote: > I am trying to get a point grey chameleon to work under Suse 12.3 > using libdc1394 + libusb. > I see from the archives that this has been done, but my camera is not > being recognized with by micromanager or by any of the examples provided > with libdc1394. > > lsusb detects the camera and prints its USB info, and the camera > function correctly udner Win7, so the camera is not broken. > > Can anyone tell me what I am missing? > > Thanks in advance > --aryeh What are the VID/PID of the camera ? libdc1394 has a static list of usb VID/PID and if the camera is not in that list it will not work. These are the VID/PID currently known to libdc1394 for the Chameleon : { 0x1e10, 0x2004 }, // Point Grey Chameleon Color { 0x1e10, 0x2005 }, // Point Grey Chameleon Mono Rodolphe -- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ | | Robotics / Unix / Mac OS X / Astronomy | |
From: David M. <dav...@gm...> - 2013-07-10 16:39:07
|
You can set the environment variable DC1394_DEBUG=1 before running any code to get more debugging info printed. Feel free to send that output here for advice. In addition to Rodolphe's suggestions, some distributions require you to use root to get access to the camera. This can be corrected if it turns out to be the problem for you. -David On Mon, Jul 8, 2013 at 11:34 AM, Aryeh Weiss <ar...@cc...> wrote: > I am trying to get a point grey chameleon to work under Suse 12.3 > using libdc1394 + libusb. > I see from the archives that this has been done, but my camera is not > being recognized with by micromanager or by any of the examples provided > with libdc1394. > > lsusb detects the camera and prints its USB info, and the camera > function correctly udner Win7, so the camera is not broken. > > Can anyone tell me what I am missing? > > Thanks in advance > --aryeh > -- > Aryeh Weiss > Faculty of Engineering > Bar Ilan University > Ramat Gan 52900 Israel > > Ph: 972-3-5317638 > FAX: 972-3-7384051 > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel > |
From: Aryeh W. <ar...@cc...> - 2013-07-10 17:04:10
|
Thank you to David and Rudolphe for your quick replies. On 7/10/13 7:04 PM, Rodolphe Pineau wrote: > > On Mon 7/8/13, at 11:34, Aryeh Weiss <ar...@cc...> wrote: > >> I am trying to get a point grey chameleon to work under Suse 12.3 >> using libdc1394 + libusb. >> I see from the archives that this has been done, but my camera is not >> being recognized with by micromanager or by any of the examples provided >> with libdc1394. >> >> lsusb detects the camera and prints its USB info, and the camera >> function correctly udner Win7, so the camera is not broken. >> >> Can anyone tell me what I am missing? >> >> Thanks in advance >> --aryeh > > > What are the VID/PID of the camera ? > libdc1394 has a static list of usb VID/PID and if the camera is not in that list it will not work. > These are the VID/PID currently known to libdc1394 for the Chameleon : > > { 0x1e10, 0x2004 }, // Point Grey Chameleon Color > { 0x1e10, 0x2005 }, // Point Grey Chameleon Mono > From lsusb -v : idVendor 0x1e10 Point Grey Research, Inc. idProduct 0x2005 There is a bunch of other output from lsusb -v. I will try running with DC1394_DEBUG=1 when I am next in that lab. Meanwhile, I received the following output to stderr when i tried to run Coriander: libdc1394 warning: usb: Failed to open device for config ROM libdc1394 warning: Failed to get config ROM from usb device I tried running as root to see if there was a privileges problem. --aryeh -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 |
From: Rodolphe P. <pi...@rt...> - 2013-07-10 17:38:00
|
On Wed 7/10/13, at 10:04, Aryeh Weiss <ar...@cc...> wrote: > > From lsusb -v : > idVendor 0x1e10 Point Grey Research, Inc. > idProduct 0x2005 > These are the right one so no funky firmware that would have messed up the VID/PID. > There is a bunch of other output from lsusb -v. > > I will try running with DC1394_DEBUG=1 when I am next in that lab. > Meanwhile, I received the following output to stderr when i tried to run > Coriander: > libdc1394 warning: usb: Failed to open device for config ROM > libdc1394 warning: Failed to get config ROM from usb device > > I tried running as root to see if there was a privileges problem. > > --aryeh This error looks like the device is already in use by something else and when the library call libusb_open it gets an error. So you have other video related application running at the same time ? Does it do the same thing if you run your code as root (directly as root or via sudo) ? Rodolphe -- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ | | Robotics / Unix / Mac OS X / Astronomy | |
From: Aryeh W. <ar...@cc...> - 2013-07-10 18:41:58
|
On 7/10/13 8:36 PM, Rodolphe Pineau wrote: > > On Wed 7/10/13, at 10:04, Aryeh Weiss <ar...@cc...> wrote: >> >> From lsusb -v : >> idVendor 0x1e10 Point Grey Research, Inc. >> idProduct 0x2005 >> > > These are the right one so no funky firmware that would have messed up the VID/PID. > >> There is a bunch of other output from lsusb -v. >> >> I will try running with DC1394_DEBUG=1 when I am next in that lab. >> Meanwhile, I received the following output to stderr when i tried to run >> Coriander: >> libdc1394 warning: usb: Failed to open device for config ROM >> libdc1394 warning: Failed to get config ROM from usb device >> >> I tried running as root to see if there was a privileges problem. >> >> --aryeh > > > This error looks like the device is already in use by something else and when the library call libusb_open it gets an error. > So you have other video related application running at the same time ? Does it do the same thing if you run your code as root (directly as root or via sudo) ? > > Rodolphe > Thank you again for your replies. I decided to set it up on my home Suse system to see what happens. Indeed, it runs when I do it as root (so I must have done something else wrong the last time I tried). There is no other video device, but that error which I reported last time will occur when I am not root. However, there is a different problem. Coriander finds the camera , but cannot control it. Here is the debug output: (coriander:8581): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ...many times libdc1394 debug: Initializing platform 0: linux libdc1394 debug: linux: Failed to open RAW1394DEV or /dev/raw1394 libdc1394 debug: Failed to initialize platform 0 libdc1394 debug: Initializing platform 1: juju libdc1394 debug: Juju: Found /dev/fw0 libdc1394 debug: Initialized platform 1 libdc1394 debug: Initializing platform 2: usb libdc1394 debug: Initialized platform 2 libdc1394 debug: Enumerating cameras... libdc1394 debug: Enumerating platform juju libdc1394 debug: Juju: Opened /dev/fw0 successfully libdc1394 debug: Platform juju has 1 device(s) libdc1394 debug: Got 256 quads of config ROM libdc1394 debug: Enumerating platform usb libdc1394 debug: usb: Found vendor:prod 1e10:2005 at address 2:4 libdc1394 debug: Platform usb has 1 device(s) libdc1394 debug: Got 37 quads of config ROM libdc1394 debug: Adding camera b09d0100c7f03f:0 b09d:1 (Point Grey Research:Chameleon CMLN-13S2M) (coriander:8581): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ...many times. --aryeb -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 |
From: Aryeh W. <ar...@cc...> - 2013-07-10 18:50:54
|
On 7/10/13 8:36 PM, Rodolphe Pineau wrote: > > On Wed 7/10/13, at 10:04, Aryeh Weiss <ar...@cc...> wrote: >> >> From lsusb -v : >> idVendor 0x1e10 Point Grey Research, Inc. >> idProduct 0x2005 >> > > These are the right one so no funky firmware that would have messed up the VID/PID. > >> There is a bunch of other output from lsusb -v. >> >> I will try running with DC1394_DEBUG=1 when I am next in that lab. >> Meanwhile, I received the following output to stderr when i tried to run >> Coriander: >> libdc1394 warning: usb: Failed to open device for config ROM >> libdc1394 warning: Failed to get config ROM from usb device >> >> I tried running as root to see if there was a privileges problem. >> >> --aryeh > > > This error looks like the device is already in use by something else and when the library call libusb_open it gets an error. > So you have other video related application running at the same time ? Does it do the same thing if you run your code as root (directly as root or via sudo) ? > > Rodolphe > One other thing -- I verified that the D-bus service is running. --aryeh -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 |
From: Aryeh W. <ar...@cc...> - 2013-07-11 08:56:37
|
After restarting my system, all of coriander's features appear to functions, and I even have an image displayed. However, I still have to run it as root. Does anyone on list know what permissions I need to set to set to be able to use it as a regular user on Suse? I looked for things like /dev/*1394* but I did not find anything. --aryeh On 7/10/13 7:38 PM, David Moore wrote: > You can set the environment variable DC1394_DEBUG=1 before running any > code to get more debugging info printed. Feel free to send that output > here for advice. > > In addition to Rodolphe's suggestions, some distributions require you to > use root to get access to the camera. This can be corrected if it turns > out to be the problem for you. > > -David > > > > On Mon, Jul 8, 2013 at 11:34 AM, Aryeh Weiss <ar...@cc... > <mailto:ar...@cc...>> wrote: > > I am trying to get a point grey chameleon to work under Suse 12.3 > using libdc1394 + libusb. > I see from the archives that this has been done, but my camera is not > being recognized with by micromanager or by any of the examples provided > with libdc1394. > > lsusb detects the camera and prints its USB info, and the camera > function correctly udner Win7, so the camera is not broken. > > Can anyone tell me what I am missing? > > Thanks in advance > --aryeh > -- -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 |
From: Roger O. <ro...@op...> - 2013-07-11 11:06:48
|
On Thursday, July 11, 2013 11:56:12 AM Aryeh Weiss wrote: > After restarting my system, all of coriander's features appear to > functions, and I even have an image displayed. > However, I still have to run it as root. > Does anyone on list know what permissions I need to set to > set to be able to use it as a regular user on Suse? > # I have put the following in a file called: /etc/udev/rules.d/99-dc1394.rules # IEEE1394 devices # KERNEL=="raw1394*", NAME="%k", GROUP="video", MODE="666", OPTIONS="last_rule" KERNEL=="dv1394*", NAME="%k", SYMLINK+="dv1394/%n", GROUP="video", MODE="666", OPTIONS="last_rule" KERNEL=="video1394*", NAME="%k", SYMLINK+="video1394/%n", GROUP="video", MODE="666", OPTIONS="last_rule" (If the text is garbled by mail, there should be three lines starting with KERNEL==, each ending with the OPTIONS= part) This makes the devices rw by everyone. On my system this is fine. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 rog...@ra... ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se |
From: Stefan R. <st...@s5...> - 2013-07-11 13:28:18
|
On Jul 11 Roger Oberholtzer wrote: > On Thursday, July 11, 2013 11:56:12 AM Aryeh Weiss wrote: > > After restarting my system, all of coriander's features appear to > > functions, and I even have an image displayed. > > However, I still have to run it as root. > > Does anyone on list know what permissions I need to set to > > set to be able to use it as a regular user on Suse? > > # > > I have put the following in a file called: /etc/udev/rules.d/99-dc1394.rules > > > # IEEE1394 devices > # > KERNEL=="raw1394*", NAME="%k", GROUP="video", MODE="666", > OPTIONS="last_rule" > KERNEL=="dv1394*", NAME="%k", SYMLINK+="dv1394/%n", > GROUP="video", MODE="666", OPTIONS="last_rule" > KERNEL=="video1394*", NAME="%k", SYMLINK+="video1394/%n", > GROUP="video", MODE="666", OPTIONS="last_rule" > > (If the text is garbled by mail, there should be three lines starting with > KERNEL==, each ending with the OPTIONS= part) > > This makes the devices rw by everyone. On my system this is fine. These rules are for FireWire cameras, not USB cameras. Furthermore, these rules are immaterial to kernels later than 2.6.36 (and also to some older kernels depending on kernel configuration). For current kernels, stock udev contains the necessary rules to make FireWire IIDC cameras accessible to users in the "video" group, as well as at least some boilerplate for distributions which prefer to do these things via ACL rather than Unix file permissions. Alas I can't answer Aryeh's question regarding USB camera access permissions. -- Stefan Richter -=====-===-= -=== -=-== http://arcgraph.de/sr/ |
From: Aryeh W. <ar...@cc...> - 2013-07-11 19:47:59
|
Thank you for your replies. Indeed, adding the rules files did not solve the issue, as Stefan wrote. I added my non-root account to the video group, but that did not help. There appear to be two issues. 1. The camera access permissions, which I can "solve" by becoming root. Unfortunately, students will need to use this system, and I dont want them to root. 2. D-bus access -- to fix this I not only have to become root, I must have root's environment (su -) Best regards, --aryeh On 7/11/13 4:27 PM, Stefan Richter wrote: > On Jul 11 Roger Oberholtzer wrote: >> On Thursday, July 11, 2013 11:56:12 AM Aryeh Weiss wrote: >>> After restarting my system, all of coriander's features appear to >>> functions, and I even have an image displayed. >>> However, I still have to run it as root. >>> Does anyone on list know what permissions I need to set to >>> set to be able to use it as a regular user on Suse? >>> # >> >> I have put the following in a file called: /etc/udev/rules.d/99-dc1394.rules >> >> >> # IEEE1394 devices >> # >> KERNEL=="raw1394*", NAME="%k", GROUP="video", MODE="666", >> OPTIONS="last_rule" >> KERNEL=="dv1394*", NAME="%k", SYMLINK+="dv1394/%n", >> GROUP="video", MODE="666", OPTIONS="last_rule" >> KERNEL=="video1394*", NAME="%k", SYMLINK+="video1394/%n", >> GROUP="video", MODE="666", OPTIONS="last_rule" >> >> (If the text is garbled by mail, there should be three lines starting with >> KERNEL==, each ending with the OPTIONS= part) >> >> This makes the devices rw by everyone. On my system this is fine. > > These rules are for FireWire cameras, not USB cameras. Furthermore, these > rules are immaterial to kernels later than 2.6.36 (and also to some older > kernels depending on kernel configuration). For current kernels, stock > udev contains the necessary rules to make FireWire IIDC cameras accessible > to users in the "video" group, as well as at least some boilerplate for > distributions which prefer to do these things via ACL rather than Unix > file permissions. > > Alas I can't answer Aryeh's question regarding USB camera access > permissions. > -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 |
From: Aryeh W. <ar...@cc...> - 2013-07-15 10:07:48
|
Thanks to Roger Oberholtzer's help, the Point Grey Chameleon is now working properly with Suse 12.3 The solution was to write a proper udev rules file to make the device available to non root users. The required rule is: SUBSYSTEM="usb", ATTR{idVendor}=="1e10", ATTR{idProduct}=="2005",MODE="0666", SYMLINK+="ptGreyCham" all on one line. The rules files are in /usr/lib/udev/rules.d The idVendor and idProduct can be found with lsusb I thought it might be useful to have this posted to the list. --aryeh -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 |
From: Stefan R. <st...@s5...> - 2013-07-15 12:54:11
|
On Jul 15 Aryeh Weiss wrote: > Thanks to Roger Oberholtzer's help, the Point Grey Chameleon is now > working properly with Suse 12.3 > > The solution was to write a proper udev rules file to make the device > available to non root users. > The required rule is: > > SUBSYSTEM="usb", ATTR{idVendor}=="1e10", ATTR{idProduct}=="2005", MODE="0666", SYMLINK+="ptGreyCham" > > all on one line. The rules files are in > /usr/lib/udev/rules.d > > The idVendor and idProduct can be found with lsusb {,/usr}/lib/udev/rules.d/ is going to be overwritten at the next update or reinstallation of the udev package. Better put this line into a file in /etc/udev/rules.d/ which is dedicated to files of the local site or host administrator. The name of the file can be chosen almost arbitrarily, with the following caveats: - The name needs to end with ".rules". - The entirety of all rules files in /etc/udev/rules.d/, /run/udev/rules.d/, and {,/usr}/lib/udev/rules.d/ is processed in lexical order of filenames, regardless in which of these directories the files are located. - If there is a pair or triplet of files with same names in /etc/udev/rules.d/ or /run/udev/rules.d/ or {,/usr}/lib/udev/rules.d/, then only one of these files is processed while the others are ignored. Files in /etc/udev/rules.d/ take precedence over ones in /run/udev/rules.d/ or {,/usr}/lib/udev/rules.d/; files in /run/udev/rules.d/ take precedence over files in {,/usr}/lib/udev/rules.d/. Instead of MODE="0666" i.e. world-writable device file, something like GROUP="video" i.e. group-writable file with group ownership set to "video" is presumably a more common choice for this kind of hardware. As a longterm solution, somebody should probably get in touch with the udev developers in order to get a suitable rule added to udev proper, similar to how it was done for FireWire cameras. -- Stefan Richter -=====-===-= -=== -==== http://arcgraph.de/sr/ |
From: Aryeh W. <ar...@cc...> - 2013-07-15 13:33:32
|
On 7/15/13 3:53 PM, Stefan Richter wrote: > On Jul 15 Aryeh Weiss wrote: >> Thanks to Roger Oberholtzer's help, the Point Grey Chameleon is now >> working properly with Suse 12.3 >> >> The solution was to write a proper udev rules file to make the device >> available to non root users. >> The required rule is: >> >> SUBSYSTEM="usb", ATTR{idVendor}=="1e10", ATTR{idProduct}=="2005", MODE="0666", SYMLINK+="ptGreyCham" >> >> all on one line. The rules files are in >> /usr/lib/udev/rules.d >> >> The idVendor and idProduct can be found with lsusb > > {,/usr}/lib/udev/rules.d/ is going to be overwritten at the next update or > reinstallation of the udev package. Better put this line into a file > in /etc/udev/rules.d/ which is dedicated to files of the local site or > host administrator. The name of the file can be chosen almost > arbitrarily, with the following caveats: > - The name needs to end with ".rules". > - The entirety of all rules files in /etc/udev/rules.d/, > /run/udev/rules.d/, and {,/usr}/lib/udev/rules.d/ is processed in > lexical order of filenames, regardless in which of these directories > the files are located. > - If there is a pair or triplet of files with same names > in /etc/udev/rules.d/ or /run/udev/rules.d/ or {,/usr}/lib/udev/rules.d/, > then only one of these files is processed while the others are ignored. > Files in /etc/udev/rules.d/ take precedence over ones in > /run/udev/rules.d/ or {,/usr}/lib/udev/rules.d/; files in > /run/udev/rules.d/ take precedence over files in {,/usr}/lib/udev/rules.d/. > > Instead of MODE="0666" i.e. world-writable device file, something like > GROUP="video" i.e. group-writable file with group ownership set to "video" > is presumably a more common choice for this kind of hardware. > > As a longterm solution, somebody should probably get in touch with the > udev developers in order to get a suitable rule added to udev proper, > similar to how it was done for FireWire cameras. > Thank you for this clarification, especially in explaining the precedence of the various rules.d directories. Roger also wrote to me about using the GROUP parameter to do the security correctly, and to put local changes in /etc/udev/rules.d --aryeh -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 |
From: Roger O. <ro...@op...> - 2013-07-15 14:16:08
|
On Monday, July 15, 2013 02:53:38 PM Stefan Richter wrote: > Instead of MODE="0666" i.e. world-writable device file, something like > GROUP="video" i.e. group-writable file with group ownership set to "video" > is presumably a more common choice for this kind of hardware. Probably a combination of MODE and GROUP where the mode is set reasonably for members of the GROUP: ,MODE=660, GROUP="video" and then assign users to the 'video' group as appropriate. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 rog...@ra... ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se |
From: Stefan R. <st...@s5...> - 2013-07-15 23:52:49
|
On Jul 15 Roger Oberholtzer wrote: > On Monday, July 15, 2013 02:53:38 PM Stefan Richter wrote: > > > Instead of MODE="0666" i.e. world-writable device file, something like > > GROUP="video" i.e. group-writable file with group ownership set to "video" > > is presumably a more common choice for this kind of hardware. > > Probably a combination of MODE and GROUP where the mode is set reasonably for > members of the GROUP: > > ,MODE=660, GROUP="video" > > and then assign users to the 'video' group as appropriate. IIRC, and as far as the contents of upstream udev rules imply, GROUP="foo" is a shorthand for GROUP="foo", MODE="0660" but I can't find explicit documentation about this at the moment. IOW if you specify GROUP, you need MODE only if you want something different from 660. (And if you don't specify GROUP, you need MODE only if you want something different from 600 of course.) -- Stefan Richter -=====-===-= -=== =---- http://arcgraph.de/sr/ |
From: Antoine V. <ant...@gm...> - 2014-10-28 10:45:31
|
hello, just for reference, on Ubuntu (14.10), the Stefan's rule doesn't work for me. but this one works : ~~~~ SUBSYSTEM=="usb", ATTR{idVendor}=="1e10", ATTR{idProduct}=="2005", MODE:="0666", OWNER:="root", GROUP:="video", SYMLINK+="ptGreyCham" ~~~~ note the double "==" between SUBSYSTEM and "usb". According to udev manual, "==" is for comparison and "=" is for assignment. I guess it was a typo. Cheers A. -- do it yourself http://antoine.villeret.free.fr 2013-07-16 1:52 GMT+02:00 Stefan Richter <st...@s5...>: > On Jul 15 Roger Oberholtzer wrote: >> On Monday, July 15, 2013 02:53:38 PM Stefan Richter wrote: >> >> > Instead of MODE="0666" i.e. world-writable device file, something like >> > GROUP="video" i.e. group-writable file with group ownership set to "video" >> > is presumably a more common choice for this kind of hardware. >> >> Probably a combination of MODE and GROUP where the mode is set reasonably for >> members of the GROUP: >> >> ,MODE=660, GROUP="video" >> >> and then assign users to the 'video' group as appropriate. > > IIRC, and as far as the contents of upstream udev rules imply, > GROUP="foo" > is a shorthand for > GROUP="foo", MODE="0660" > but I can't find explicit documentation about this at the moment. IOW if > you specify GROUP, you need MODE only if you want something different from > 660. (And if you don't specify GROUP, you need MODE only if you want > something different from 600 of course.) > -- > Stefan Richter > -=====-===-= -=== =---- > http://arcgraph.de/sr/ > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel |
From: Stefan R. <st...@s5...> - 2014-10-28 18:14:48
|
On Oct 28 Antoine Villeret wrote: > hello, > > just for reference, on Ubuntu (14.10), the Stefan's rule doesn't work for me. > > but this one works : > > ~~~~ > SUBSYSTEM=="usb", ATTR{idVendor}=="1e10", ATTR{idProduct}=="2005", > MODE:="0666", OWNER:="root", GROUP:="video", SYMLINK+="ptGreyCham" > ~~~~ > > note the double "==" between SUBSYSTEM and "usb". > > According to udev manual, "==" is for comparison and "=" is for assignment. > I guess it was a typo. > > Cheers > > A. Stock udev contains rules for FireWire cameras to which I contributed some time ago, but I never had a hand in the creation of rules for USB cameras. So, not sure what you mean by "Stefan's rule". :-) Furthermore, stock udev provides rules for FireWire cameras which (a) change the device node's group ownership to video (but do not grant access to the world) and (b) set access permission via ACL to the current console owner. Both mechanisms work e.g. in Gentoo Linux just like intended by upstream udev. I don't know whether Ubuntu 14.10 provides different rules and mechanisms. If merely changing group ownership to "video" is not sufficient for you, then I would guess that your user account is not member of the video group. On the other hand, if you grant access for all (mode 0666), then I would expect that there is no need to specify/ modify onwership. Unless udev does something really weird if mode but not owner/group is given. Anyhow, thanks for the heads-up. > do it yourself > http://antoine.villeret.free.fr > > > 2013-07-16 1:52 GMT+02:00 Stefan Richter <st...@s5...>: > > On Jul 15 Roger Oberholtzer wrote: > >> On Monday, July 15, 2013 02:53:38 PM Stefan Richter wrote: > >> > >> > Instead of MODE="0666" i.e. world-writable device file, something like > >> > GROUP="video" i.e. group-writable file with group ownership set to "video" > >> > is presumably a more common choice for this kind of hardware. > >> > >> Probably a combination of MODE and GROUP where the mode is set reasonably for > >> members of the GROUP: > >> > >> ,MODE=660, GROUP="video" > >> > >> and then assign users to the 'video' group as appropriate. > > > > IIRC, and as far as the contents of upstream udev rules imply, > > GROUP="foo" > > is a shorthand for > > GROUP="foo", MODE="0660" > > but I can't find explicit documentation about this at the moment. IOW if > > you specify GROUP, you need MODE only if you want something different from > > 660. (And if you don't specify GROUP, you need MODE only if you want > > something different from 600 of course.) -- Stefan Richter -=====-====- =-=- ===-- http://arcgraph.de/sr/ |
From: Antoine V. <ant...@gm...> - 2014-10-28 18:31:07
|
oups sorry, I was referring to Aryeh Weiss' rule he sent on July 15th, 2013. Sorry Aryeh for the mistake. Concerning the rest, you're right, my rule is not the best, I should remove the "MODE". At least there is no reason to use both MODE and GROUP/OWNER keywords at the same time. + a -- do it yourself http://antoine.villeret.free.fr 2014-10-28 19:14 GMT+01:00 Stefan Richter <st...@s5...>: > On Oct 28 Antoine Villeret wrote: >> hello, >> >> just for reference, on Ubuntu (14.10), the Stefan's rule doesn't work for me. >> >> but this one works : >> >> ~~~~ >> SUBSYSTEM=="usb", ATTR{idVendor}=="1e10", ATTR{idProduct}=="2005", >> MODE:="0666", OWNER:="root", GROUP:="video", SYMLINK+="ptGreyCham" >> ~~~~ >> >> note the double "==" between SUBSYSTEM and "usb". >> >> According to udev manual, "==" is for comparison and "=" is for assignment. >> I guess it was a typo. >> >> Cheers >> >> A. > > Stock udev contains rules for FireWire cameras to which I contributed some > time ago, but I never had a hand in the creation of rules for USB > cameras. So, not sure what you mean by "Stefan's rule". :-) > > Furthermore, stock udev provides rules for FireWire cameras which (a) > change the device node's group ownership to video (but do not grant access > to the world) and (b) set access permission via ACL to the current console > owner. Both mechanisms work e.g. in Gentoo Linux just like intended by > upstream udev. I don't know whether Ubuntu 14.10 provides different rules > and mechanisms. > > If merely changing group ownership to "video" is not sufficient for you, > then I would guess that your user account is not member of the video group. > > On the other hand, if you grant access for all (mode 0666), then I would > expect that there is no need to specify/ modify onwership. Unless udev > does something really weird if mode but not owner/group is given. > > Anyhow, thanks for the heads-up. > > >> do it yourself >> http://antoine.villeret.free.fr >> >> >> 2013-07-16 1:52 GMT+02:00 Stefan Richter <st...@s5...>: >> > On Jul 15 Roger Oberholtzer wrote: >> >> On Monday, July 15, 2013 02:53:38 PM Stefan Richter wrote: >> >> >> >> > Instead of MODE="0666" i.e. world-writable device file, something like >> >> > GROUP="video" i.e. group-writable file with group ownership set to "video" >> >> > is presumably a more common choice for this kind of hardware. >> >> >> >> Probably a combination of MODE and GROUP where the mode is set reasonably for >> >> members of the GROUP: >> >> >> >> ,MODE=660, GROUP="video" >> >> >> >> and then assign users to the 'video' group as appropriate. >> > >> > IIRC, and as far as the contents of upstream udev rules imply, >> > GROUP="foo" >> > is a shorthand for >> > GROUP="foo", MODE="0660" >> > but I can't find explicit documentation about this at the moment. IOW if >> > you specify GROUP, you need MODE only if you want something different from >> > 660. (And if you don't specify GROUP, you need MODE only if you want >> > something different from 600 of course.) > > -- > Stefan Richter > -=====-====- =-=- ===-- > http://arcgraph.de/sr/ |