Description of problem: When running dvgrab as an ordinary user the following error appears: [maxx@ice ~]$ dvgrab -autosplit -format raw -size 0 -timestamp foo- Error: no camera exists Running as root correctly starts the grabbing proces. Version-Release number of selected component (if applicable): kernel-2.6.25-14.fc9.i686 libavc1394-0.5.3-2.fc9.i386 libraw1394-1.3.0-6.fc9.i386 libdc1394-2.0.1-4.fc9.i386 dvgrab-3.1-2.fc9.i386 How reproducible: Always Steps to Reproduce: 1. Connect dv camera 2. Run dvgrab as ordinary user 3. See error Actual results: Error Expected results: Grabbing should start Additional info: The following appears in /var/log/messages when connecting camera: May 3 19:59:41 localhost kernel: firewire_core: BM lock failed, making local node (ffc0) root. May 3 19:59:41 localhost kernel: firewire_core: phy config: card 0, new root=ffc0, gap_count=5 May 3 19:59:42 localhost kernel: firewire_core: phy config: card 0, new root=ffc1, gap_count=5 May 3 19:59:45 localhost kernel: firewire_core: created device fw1: GUID 0000f0000c480971, S400, 1 config ROM retries
Access permissions should be properly set when you do a graphical login (works for me, anyhow). Is this an ssh login or console login, by chance? I suppose we ought to have something that works there too, if it doesn't...
This is with a graphical login (GNOME if it makes a difference). After plugging in the camera here is what I get: [maxx@ice defs]$ ll /dev/fw* crw-rw---- 1 root root 248, 0 2008-05-04 08:00 /dev/fw0 crw-rw----+ 1 root root 248, 1 2008-05-04 21:45 /dev/fw1
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Crap. I've got the same thing happening on my own F9 laptop now. I'll see what I can figure out...
(In reply to comment #4) > Crap. I've got the same thing happening on my own F9 laptop now. I'll see what I > can figure out... Jarod, it seems to me that, on F9, /etc/security/console.perms.d/50-default.perms is missing some entry for the "fw" devices. Maybe this is a "pam" issue... pg
Nope, firewire device access control is no longer handled by console.perms, its handled by hal, via /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi. I'm clueless about these inner workings though, no idea why its not working, since I clearly see the ieee1394-avc device type defined in there alongside the ieee1394-iidc device type, which does work... I think I'm going to kick this bug over to the hal component, I'm guessing the hal folks might have an idea off the top of their heads what's wrong.
Ah, fun... So I think I see part of why dvgrab is falling down, while iidc is working... dvgrab actually needs read/write perms on the fw* device node of the controller the camera is hooked to, it would appear. Just chowning the device node of the camera to my user still results in no camera found, but chowning the device node of the controller the camera is hooked to gets things working. Not quite sure how we handle this in hal though, since I'm not sure it knows (or is even supposed to know) which device node is the controller the camera is hooked to...
(In reply to comment #7) > Ah, fun... So I think I see part of why dvgrab is falling down, while iidc is > working... dvgrab actually needs read/write perms on the fw* device node of the > controller the camera is hooked to, it would appear. Just chowning the device Now that you mention I remember I reached the same conclusion while playing around with dvgrab & kino. It could even be, not sure, that *only* the controller node need to be "rw" by the user accessing the camera (to be confirmed). Could it be a libraw1394 issue? Maybe it is not really correct what is done there... pg
After chowning /dev/fw0 (the controller, I guess, as /dev/fw1 seems to be the camera), I am able to run dvgrab as myself, but I do get these additional two warnings: Warning: Cannot set RR-scheduler Warning: Cannot disable swapping Is dvgrab only meant to be run as root? How might one reasonably allow an ordinary user process to make such adjustments? (I haven't looked at the dvgrab source to see what it's trying to do, but I can guess pretty well.)
(In reply to comment #9) > After chowning /dev/fw0 (the controller, I guess, as /dev/fw1 seems to be the > camera), I am able to run dvgrab as myself, but I do get these additional two > warnings: > > Warning: Cannot set RR-scheduler > Warning: Cannot disable swapping > > Is dvgrab only meant to be run as root? How might one reasonably allow an > ordinary user process to make such adjustments? (I haven't looked at the dvgrab > source to see what it's trying to do, but I can guess pretty well.) I don't recall getting these messages when running as non-root myself, but I'd have to double-check that. We're definitely meant to run as non-root though.
Any news on this topic? The problem seems to affect also F10, if it is just a hal configuration problem, maybe it would be worth to try some fix. Thanks, pg
Related closely to bug 441073. In fact, I'm going to close-dupe this one, since its not moved anywhere in 5 months, and Stefan has some useful suggestions in the other one. *** This bug has been marked as a duplicate of bug 441073 ***