raw1394 does not allow for udev

[Mike White]

After installing the libraw1394-5 package, the /dev/raw1394 node does not exist,
even after the raw1394 module is loaded. dpkg-reconfigure -plow libraw1394-5
reports that the dev node is created, but it still doesn't show up.

To reproduce on a fresh ubuntu warty amd64 system:

1. Observe that /dev/raw1394 doesn't exist
2. apt-get install libraw1394-5
3. modprobe raw1394
4. /dev/raw1394 still doesn't exist, testlibraw fails.
5. /dev/MAKEDEV raw1394, /sbin/MAKEDEV raw1394
6. /dev/raw1394 still doesn't exist, testlibraw fails.
7. mknod /dev/raw1394 c 171 0
8. /dev/raw1394 now exists, testlibraw runs fine

[Mike White (lists1)]

See also this forum thread:

http://ubuntuforums.org/showthread.php?t=2792

[Andy Wingo (andywingo)]

I experience the same problem. I'll do the workaround mentioned in the forum,
but there appears to be a kernel patch to fix this issue:

http://lkml.org/lkml/2004/11/14/6

I'm running hoary btw.

[Matt Zimmerman (mdz)]

*** Bug 13880 has been marked as a duplicate of this bug. ***

[Mantas Kriaučiūnas (mantas)]

this bug could be solved very simple, with one line patch to
/etc/udev/links.conf - just add line:

M raw1394 c 171 0

to the end of /etc/udev/links.conf

I found this solution in Mandrake's udev packages (see file udev-links.conf.bz2
in any mandrake udev src.rpm package, newer than 050, for example
udev-054-2mdk.src.rpm )

Please, fix this bug ASAP - hoary should have working firewire subsystem and
users should have an ability to work with firewire devices, for example to
capture movies from digital video cameras

[Chuck Short (zulcss)]

*** Bug 13980 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

This is not a fix, but a workaround (the real bug is in the driver itself).

However, we don't have time to fix this properly at this point, and the
workaround is simple and safe, so it should be applied for Hoary.

[j^ (j)]

what about the permissions?
adding
M raw1394 c 171 0
D video1394
M video1394/0 c 171 16
to the end of /etc/udev/links.conf
and
raw1394:root:video:660
video1394:root:video:660
video1394/*:root:video:660

to /etc/udev/permissions.d/udev.permissions

ls -la /dev/raw1394
crw------- 1 root root 171, 0 2005-03-14 22:16 /dev/raw1394

it looks like udev does not apply permissions to devices added via
/etc/udev/links.conf

[j^ (j)]

with this patch udev would change permissions for files
created via /etc/udev/links.conf

--- /etc/init.d/udev.orig 2005-03-14 22:40:49 +0100
+++ /etc/init.d/udev 2005-03-14 22:41:33 +0100
@@ -74,7 +74,10 @@
     case "$type" in
       L) ln -s $arg1 /dev/$name ;;
       D) mkdir -p /dev/$name ;;
- M) mknod --mode=600 /dev/$name $arg1 ;;
+ M) mknod --mode=600 /dev/$name $arg1
+ grep $name: /etc/udev/permissions.d/* | \
+ sed "s/^.*:\(.*\):\(.*\):\([0-9]*\)/chown \1:\2 \/dev\/$(echo $name |
sed 's/\//\\\//g'); chmod \3 \/dev\/$(echo $name | sed 's/\//\\\//g')/g" | sh
+ ;;
       *) log_warning_msg "links.conf: unparseable line ($type $name $arg1)" ;;
     esac
   done

[gratefulfrog (gratefulfrog)]

(In reply to comment #7)
> what about the permissions?
> adding
> M raw1394 c 171 0
> D video1394
> M video1394/0 c 171 16
> to the end of /etc/udev/links.conf
> and
> raw1394:root:video:660
> video1394:root:video:660
> video1394/*:root:video:660

Sorry to ask what certainly is a stupid question, but what about /dev/dv1394 which is
also needed for DV editing with Kino and/or Cinelerra?

(how does one know the numbers to feed to mknode?)

[j^ (j)]

> Sorry to ask what certainly is a stupid question, but what about /dev/dv1394
which is
> also needed for DV editing with Kino and/or Cinelerra?
>
> (how does one know the numbers to feed to mknode?)
from http://www.linux1394.org/dv1394.php
its
M dv1394 c 171 32
for NTSC
and
M dv1394 c 171 34
for PAL

[Vytautas (vytautas-germanavicius)]

Will be able to use firewire devices in ubuntu hoary?

[Jeff Bailey (jbailey)]

(In reply to comment #8)

> + M) mknod --mode=600 /dev/$name $arg1
> + grep $name: /etc/udev/permissions.d/* | \
> + sed "s/^.*:\(.*\):\(.*\):\([0-9]*\)/chown \1:\2 \/dev\/$(echo $name |
> sed 's/\//\\\//g'); chmod \3 \/dev\/$(echo $name | sed 's/\//\\\//g')/g" | sh
> + ;;

grep "^${name}:" /etc/udev/permissions.d/udev.permissions | while IFS=: read a b
c d; do chown ${b}:${c} /dev/${a}; chmod ${d} /dev/${a}; done

does the same thing, while being quite a bit more readable. Both have the
problem that the permissions file specifies a wildcard, which won't be picked up
by the grep.

Since we're manually configuring this for now, I'm going to just hardcode it to
a 0 with a note to change it.

I'm not doing /dev/dv1394, since it can refer to two different device major,
minors. Unless I can find a heuristic to determine PAL from NTSC automatically,
this has to be done in the driver.

[Jeff Bailey (jbailey)]

Uploaded, closing this bug now.

[gratefulfrog (gratefulfrog)]

(In reply to comment #13)
> Uploaded, closing this bug now.

I've just tried the latest Hoary (2005 04 09) update and can say that:
- the hotplug of an IEEE1394 device now does create both /dev/raw1394 and
/dev/video1394
- the permissions of raw1394 are:
cr-------- 1 root video 171, 0 2005-04-09 18:06 raw1394

but all users require r+w access... so I think that this bug isn't really fixed
(but this might just be my misunderstanding due to my own ignorance, sorry in
advance if that is the case...;)

[Matt Zimmerman (mdz)]

(In reply to comment #14)
> (In reply to comment #13)
> > Uploaded, closing this bug now.
>
> I've just tried the latest Hoary (2005 04 09) update and can say that:
> - the hotplug of an IEEE1394 device now does create both /dev/raw1394 and
> /dev/video1394
> - the permissions of raw1394 are:
> cr-------- 1 root video 171, 0 2005-04-09 18:06 raw1394

The permissions of the device are a separate issue; please file it as a separate
bug.

[Dan Dennedy (dan-dennedy)]

Kernel ieee1394 can support this since 2.6.12. See
http://www.linux1394.org/faq.php#udev