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):
Steps to Reproduce:
1. Connect dv camera
2. Run dvgrab as ordinary user
3. See error
Grabbing should start
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
May 3 19:59:42 localhost kernel: firewire_core: phy config: card 0, new
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:
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
Maybe this is a "pam" issue...
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
(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...
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
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
> 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.
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 ***