In that case you should expect that running as root would allow it to
work, but you reported it is not. If both ieee1394 and firewire
subsystems are enabled in the kernel, then it may create this problem:
grep FIREWIRE /boot/config-$(uname -r)
--
DV capture over Firewire is broken
https://bugs.l
Kino has not supported video1394 for years. You are meaning dv1394 when
you write "video1394." Also, why do you think I did not enable that
option by default? The answer is that it imposes major usability issues.
The new firewire subsystem and libraw1394 2.0 have resolved the security
issue with u
I have developed a simple patch for raw1394 that I am just beginning to
test that addresses the raw1394 security issue in a way completely
different than Jody's proposal. One drawback to using many different
device files is the impact of that change on the libraries and
applications that will take
Yeah, linux1394 was late to the udev game, and I suspect the kernel name
will be a popular default for udev rule makers. I believe Dapper will be
a popular version for quite a while. Oh well, I will consider changing
the Kino default dv1394 device name or simply try a few popular names in
addition
*** This bug is a duplicate of bug 6290 ***
dv1394 does not implement the camera control protocol. libavc1394, which
uses raw1394 does. Why? Well, it is a matter of these being different
protocol from differing standards bodies and the history of their
implementations. It is still possible to capt
On Thursday 25 May 2006 01:59, preciousp wrote:
> I think that in dapper it needs to use /dev/dv1394-0 rather than raw1394
> (which is a security risk).
Can Ubuntu consider using "dv1394/0" rather than "dv1394-0" per the
convention attempting to be established at
http://www.linux1394.org/faq.ph
Kino is not able to use video1394, and usage of video1394 for DV is
deprecated. The best solution at the moment is to create a new group for
raw1394.
On Thursday 25 May 2006 07:04, preciousp wrote:
> Hope you don´t mind me asking but could you guide me (and others) on what
> to do.
> Is it.
> 1.
Thank you for not revolting at my tone in my earlier response. I agree we need
to improve the kernel interface, and the issue has come up in the
linux1394-devel mailing list. However, I do not forsee a solution coming in the
near-to-mid-term. In the meantime, I was hoping to give users something
People who have no idea what they are talking about when it comes to Linux 1394
should not be trusted as an authority in this matter. What is so difficult
about creating a group named "raw1394" and assigning group ownership of
/dev/raw1394 to it? Then, any user who trusts themselves on their own
