[gutsy/hardy/intrepid] Kino can't capture video

[Duncan Lithgow]

Ubuntu Gutsy, installed from Tribe 5 CD. Updated October 13th. This camera and this system works fine capturing with Kino on Feisty.

We're right back to the old message:

'Edit > Preferences > IEEE1394'

-----------------
The IEEE 1394 Subsystem is not responding.

The raw1394 module must be loaded, and you must have read and write access to /dev/raw1394
-----------------

I'm a maintainer of https://help.ubuntu.com/community/Firewire

On Hardy /dev/raw1394 is a member of the disk group.
The file at '/dev/dv1394/0' should be the solution to this problem, but clearly it isn't. Bug #219400 in Hardy is preventing me seeing the permissions of dv3945/0.

The Kino manual says:

The dv1394 device field only appears if Kino is configured at build time using the --with-dv1394 option.

...so is that the problem?

Also although /etc/udev/rules.d/40-permissions.rules assign dv1394 to the video group, I can't find a group called video.

[Duncan Lithgow (duncan-lithgow)]

(Works as root)

[Mikael Nilsson (mini)]

How was this solved in Feisty?

[Mikael Nilsson (mini)]

I also see this.

[hkootstra (hkootstra)]

I have the same problem, it worked fine in feisty, now nothing...

[Michael Marte (informarte)]

It did not work for me in feisty either. I guess it's a configuration problem in the hardware abstraction layer. My workaround is:

su
modprobe raw1394
chmod a+w /dev/raw1394

[Duncan Lithgow (duncan-lithgow)]

If you're having trouble with capture, please read https://help.ubuntu.com/community/Firewire

[David Filiatrault (david-filiatrault)]

On kubuntu Hardy Alpha 3, running from command line: "kdesu kino" worked. Running from menu as installed resulted in the same error as in the description

[James Bardin (jbardin-deactivatedaccount)]

Since raw1394 access can't really be given to users, we have to find some sort of workaround that makes itself obvious.

How about the possibility of policykit integration (I know that can't be done for hardy)?

We could have a better error message with instructions when /dev/raw1394 exists, but isn't accessible.
Maybe using a separate group for the device, and presenting the user with instructions on which group they need to be added to during package installation (since it's not in by default).

Note that adding the user to the "disk" group didn't work on hardy (as of 4/21/08).

[Duncan Lithgow (duncan-lithgow)]

@James: 'The file at '/dev/dv1394/0' should be the solution to this problem' /dev/dv1394/0' gives access to capture dv over firewire without the security risks. But Kino has to be compiled with a certain flag or it won't look for the '/dev/dv1394' file, I understand this is because of some transition from using the dv1394 file to using something else - but I don't know what.

[James Bardin (jbardin-deactivatedaccount)]

@Duncan
Except that /dev/dv1394 doesn't provide full functionality, as the user can't operate the playback controls (unless something has changed from last time I looked into this). IMO, I think that some sort of controlled privilege elevation is the right way to go.

[Duncan Lithgow (duncan-lithgow)]

@James: I agree totally - I just haven't heard anyone suggest a way of doing this that the dev team thinks is acceptable.

[Scott James Remnant (Canonical) (canonical-scott)]

I'm unsure why you've opened a udev task for this bug? I have marked it as Invalid.

[Scott James Remnant (Canonical) (canonical-scott)]

For the record, the simple fact is that the kernel firewire subsystem is entirely inadequate for your needs.

In past bugs, people have compared the expected functionality with the USB subsystem, but now compare the implementation.

For USB, we have, for each single device, a multitude of sysfs kobjects. There is a kobject for each hub on the wire, and under that a kobject for each port the hub has, and under that a kobject for each connected device (with a variety of interesting properties) and under that a kobject for each interface and endpoint that device has.

This gives us a great deal of flexibility to customise and limit the access to USB devices. At the very least, we can apply permissions on a device by device basis (ie. one user can access the iPod and another can access the camera); at the extreme case we can customise permissions on the actual interfaces.

Now look at Firewire.

You have a single kobject for the entire firewire host, with sometimes a kobject for the device directly connected to that host. No thought for hubs or multiple devices is given at all.

There are specialist subsystems that provide limited access to certain devices (dv1394, ieee1394, video1394, etc.) but they do not seem to have the functionality the applications require.

Instead applications use a "raw1394" device that provides complete and unfettered access to all 1394 devices on all hosts. It would be equivalent to having a "/dev/usb" that you could directly use to talk to any USB device.

To make matters worse, the IEEE1394 specification permits connected devices to execute code on the host system as a super-user. It is a relatively simple matter to construct a device that you can write arbitrary code to, and requests that it is executed. Opening /dev/raw1394 to ordinary users gives root access.

The ideal solution is for the kernel's firewire subsystem to have a complete, ground-up overhaul and be written much more along the lines of the USB subsystem.

Failing that, an interim solution would be if we could at least have some information from the kernel about _WHAT_ is connected on the firewire port when they are connected and disconnected, we don't even get that right now!

If we had insert notification, with vendor and device ids inside the uevent, we could at least enable access on a "per known device" basis -- I'd still be nervous about raw1394 though, since anyone can fake a device id pair.

[Duncan Lithgow (duncan-lithgow)]

I marked this as a udev bug because something has been changed in the permissions system between Feisty and later versions.

In Feisty dv1394 was accessible to Kino (dvgrab) with no user interaction. I assume that this was some kind of 'read only' connection, I think that's part of the point of having dv1394. I don't know exactly what changed but my guess is the udev permissions.

I have also seen in the Kino documentation that for it to search for the presence of dv1394 a flag must be set at compile time. I have not yet had a reply from Mattius Klose (https://edge.launchpad.net/ubuntu/+source/kino) who I think packaged Kino for Hardy.

[teledyn (garym-teledyn)]

on mine, I see /dev/raw1394, it is root.video and I am in the video group, yet in Kino the dialog for setting the ieee1394 device is an empty pull-down list; I get the same behaviour when I run kino under sudo. lsmod shows the raw1394 module is loaded, and the syslog shows "ieee1394: raw1394: /dev/raw1394 device initialized" ... but there is no capture under Kino.

is there a more primative test for Firewire? Something command line that I can use instead of having to fire up kino and nav the menus over and over?

[Mantas Kriaučiūnas (mantas)]

I've fixed this bug - in previous Ubuntu versions Kino was compiled with --with-dv1394 instead of --without-dv1394, but in 7.10 (and in 8.04) someone forgot this and since Ubuntu 7.10 debian/rules contains --without-dv1394, like in Debian.
I've changed this to --with-dv1394, like in Ubuntu 7.04 Feisty. This is the only way to get kino working in Ubuntu as we still use dv1394 for firewire video input/output.
Also I've merged Ubuntu changes with latest Debian packages (version 1.3.0), anyone can download sources and deb file from ftp://ftp.akl.lt/Linux/Baltix/Baltix-Ubuntu-packages/hardy/kino-video-editor/
Ubuntu kino maintainers, please use my diff.gz from location above for Ubuntu Intrepid.

[teledyn (garym-teledyn)]

I find the line "dv1384 Device" now appears in my Preferences, although the AV/C Device pulldown is still empty; when Kino begins I see

>> Starting Editor
>>> dv1394Writer::dv1394Writer /dev/raw1394 channel 63 fd 6

Unfortunately the Capture page carries a warning that the

dv1394 devices is not loaded or failure to read/write /dev/dv1394

it is loaded:

dv1394 20664 0
raw1394 29400 0
ohci1394 34096 1 dv1394
ieee1394 95544 4 dv1394,raw1394,sbp2,ohci1394

Syslog says

[128306.656557] NOTE: The dv1394 driver is unsupported and may be removed in a future Linux release. Use raw1394 instead.

crw-rw---- 1 root video 171, 32 2008-05-27 08:13 /dev/dv1394/0
crw-rw---- 1 root video 171, 0 2008-05-25 19:04 /dev/raw1394

I also tried a+rw and tried running this new Kino as root, same result.

While on the Capture page the kino logging keeps printing

dv1394 INIT ioctl: Invalid argument

I then set the Preferences dv1394 to /dev/dv1394/0 (because it seemed logical that the dv device should be the dv device) and the controls on the Capture page became un-greyed, except for the AV/C, but when I tried starting my camera and clicking Record, the camera was playing back video but Kino timed out waiting for a signal.

[Neil Wilson (neil-aldur)]

Attached is the debdiff which activates the dv1394 facility.

kino (1.1.1-1ubuntu3) hardy; urgency=low

  * debian/rules: change without-dv1394 to with-dv1394 (closes #LP152392)

[teledyn (garym-teledyn)]

this patch gives me the option to set the device to /dev/dv1394/0 but with the camera playback rolling, there is still no capture, even when run as root.

>>> Using dv1394 capture
>> Leaving Capture
>> Constructing File Capture tracker
>> Starting Capture
>>> Using dv1394 capture
>> AV/C Enabled
>> Kino Common newFile
>> Leaving Capture
>> Starting Editor
>>> dv1394Writer::dv1394Writer /dev/dv1394/0 channel 63 fd 6

$ ls -l /dev/dv1394/0
crw-rw---- 1 root video 171, 32 2008-06-01 23:42 /dev/dv1394/0

is it possible that the Dell Inspiron's ieee1394 port is somehow non-standard and unsupported under Linux? it is odd that the device loads and everything seems fine, but there is just no data flowing. dmesg simply says

[ 28.348066] ieee1394: Host added: ID:BUS[0-00:1023] GUID[434fc0003bda4981]
[130759.413036] NOTE: The dv1394 driver is unsupported and may be removed in a future Linux release. Use raw1394 instead.

and lspci says

03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)

[Neil Wilson (neil-aldur)]

@teledyn

Have you tried 'dvgrab', which is the command line wrapper around the kino capture facility. That way you can easily use 'sudo dvgrab' and it will use the raw iee1394 device - including starting the playback automatically on the DV device.

If this doesn't work then the problem is probably not with kino but with the underlying ieee1394 driver and you should raise a bug with that.

The patch I've put forward just allows a normal user to use capture directly from the menu rather than having to do 'gksudo kino' in a terminal.

[teledyn (garym-teledyn)]

Neil -- thanks for that strategy advice, I will try that. I had thought
dvgrab and kino were the same code, which is why I raised the issue
here first (since there were already issues overlaying the kino
capture that seemed to preclude any success.

I'm also going to try and obtain a second cable ;)

--
Gary Lawrence Murphy <garym at teledyn.com> =============================
blog.teledyn.com -==- improvisato.blogspot.com -==- bandbook.blogspot.com
======================= the Universe is smarter than we are (Alan Watts)

[Daniel Holbach (dholbach)]

Oliver: can you please take a look at it?

[Scott James Remnant (Canonical) (canonical-scott)]

dv1394 is going away in the kernel :-(

[Tree MendUs (tree-mendus-deactivatedaccount)]

Dan (the Kino man) has a video on the kino site.
It shows what to do to check loaded "modules", groups, and permissions.
It will recognize the camera type.

[Stefan Richter (stefan-r-ubz)]

Scott James Remnant wrote on 2008-04-24:
> ...

The statements about IEEE 1394 and about what the linux1394 stack does are... somewhat inaccurate. I won't comment further.

> Failing that, an interim solution would be if we could at least have some information
> from the kernel about _WHAT_ is connected on the firewire port when they are connected
> and disconnected, we don't even get that right now!

Wrong, you do get that. There are kobjects and uevents for each unit on each node, including the AV/C unit of a camcorder for example.

> If we had insert notification, with vendor and device ids inside the uevent, we could at
> least enable access on a "per known device" basis -- I'd still be nervous about raw1394
> though, since anyone can fake a device id pair.

Indeed; it doesn't make sense to use these uevents to change /dev/raw1394's ownership and permissions or ACL because the basic problems of
  1.) ohci1394 having physical DMA enabled,
  2.) /dev/raw1394 being used for all devices
don't go away. (Both of these issues are addressed by the new firewire stack.)

[Stefan Richter (stefan-r-ubz)]

Scott James Remnant wrote on 2008-06-09:
> dv1394 is going away in the kernel :-(

Nowadays I think that dv1394 will remain in the mainline as long as the ieee1394 driver stack remains in there. However, it is important to make it known that the dv1394 ABI is deprecated because there is no direct replacement for it in the new firewire stack (in contrast to the raw1394 and video1394 ABIs for which there is a migration path to firewire-core's ABI).