[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
*** This bug is a duplicate of bug 6290 *** https://bugs.launchpad.net/bugs/6290 Hi weliad, I don't have one myself, but I believe the situation with firewire cameras has changed in Karmic--though it's still not perfect. Also, your bug report actually targets multiple issues (raw1394 module loading, raw1394 access rights, popup dialog). Furthermore, a bug without a package will rarely be seen by anyone except for bug triagers like myself. Due to these three reasons, I am marking this bug as a dupe of previously-mentioned bug 6290. Please file an additional report (against kino, I suppose?) if you would also like to see a popup dialog when plugging in the device. Thank you for your report; the community appreciates your efforts to improve Ubuntu. Please continue to report any other problems you may find. ** This bug has been marked a duplicate of bug 6290 DV capture over Firewire is broken (no rights for /dev/raw1394) -- raw1394 DV sampling should work out-of-the-box https://bugs.launchpad.net/bugs/300239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
OK, this is how it should be; raw1394 _should_ be automatically loaded with that when a DV device appears. Could be that the drivers have a special problem with your particular camera. Your local change to the udev rules does not influence autoloading, only how device file ownership is set up when /dev/raw1394 is created. -- raw1394 DV sampling should work out-of-the-box https://bugs.launchpad.net/bugs/300239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
just ran on the same issue on Jaunty rc, I spent hours today trying to fix it, this was on 2 different computers (both on jaunty rc), raw1394 didn't load when the camera (panasonic NVGS150) was pluged in. add raw1394 to /etc/modules was easy, but it took me ages to find how to grant permission to the user by editing /lib/udev/rules.d/50-udev- default.rules addingKERNEL==raw1394, GROUP=video in it. I'm not an expert at all, but most people i get to switch to ubuntu don't have a clue about computers.. and they will never figure out how to get this to work, so i agree 2000% with weliad that something has to be done as soon as possible to fix this situation. Now that softs like kdenlive are getting mature and bringing easy video editing to the ubuntu users more and more people will bump into this kind of situation. -- raw1394 DV sampling should work out-of-the-box https://bugs.launchpad.net/bugs/300239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
Why does Ubuntu (or only your two test boxes?) not load raw1394 automatically when a DV device is plugged in? Are the module aliases somehow missing in Ubuntu's raw1394? (Run modinfo raw1394.) Or does Ubuntu have a blacklist raw1394 directive somewhere in /etc? (Run grep -r 'blacklist raw1394' /etc/.) Or was the ieee1394 driver for some reason unable to identify your camera as DV device, thus never generated the hotplug even (so-called uevent) which would tell the userland to load raw1394? (The dmesg output would help to answer this.) See my previous comment. I would like to get more info about what's happening on Ubuntu since I do not have Ubuntu installed myself, hence can't check myself easily. -- raw1394 DV sampling should work out-of-the-box https://bugs.launchpad.net/bugs/300239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
(i updated the kernel to 2.6.30rc2 in the meantime i hope it doesn't disturb the info) (i ran the commands you told with the workaround still applied, should i disable it?) modinfo raw1394 filename: /lib/modules/2.6.30-020630rc2-generic/kernel/drivers/ieee1394/raw1394.ko licence: GPL srcversion: 25F083B33EFF4EE82441D63 alias: ieee1394:ven*mo*spA02Dver0102* alias: ieee1394:ven*mo*spA02Dver0101* alias: ieee1394:ven*mo*spA02Dver0100* alias: ieee1394:ven*mo*spA02Dver00010001* depends: ieee1394 vermagic: 2.6.30-020630rc2-generic SMP mod_unload modeversions 586 following your instructions i found this in the blacklist, but raw1394 seems comented: #blacklist ohci1394 #blacklist sbp2 #blacklist dv1394 #blacklist raw1394 #blacklist video1394 blacklist firewire-ohci blacklist firewire-sbp2 I don't have the camera right now to check the dmesg output, i'll check it during the week probably on a fresh install of jaunty final. -- raw1394 DV sampling should work out-of-the-box https://bugs.launchpad.net/bugs/300239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
[raw1394 not loaded automatically] Could you post the output of modinfo raw1394? I'd like to check whether all device identifiers are in there as they should be. May be necessary to run it as root or to run it as /sbin/modinfo raw1394. Also, if you have the camcorder around, please plug it in/ switch it on and post the result of dmesg | tail -100 or at least the part of that which relates to the camcorder. [driver upgrade] Well, I didn't suggest that Ubuntu users should go try test kernels. This was just meant as a note that there is some development going on which will address the Ubuntu maintainers' security concerns (which I don't quite share). [promise of a works-out-of-the-box experience] Well, I don't know what promises Ubuntu really made. Anyway; reports like yours are important to come closer to that goal. -- raw1394 DV sampling should work out-of-the-box https://bugs.launchpad.net/bugs/300239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
(I am maintainer of the upstream kernel's IEEE 1394 driver subsystem. I don't have Ubuntu myself.) 8. Realize you need to modprobe raw1394 module into your running kernel. This could be a problem with Ubuntu's udev setup, or it could be a problem at the kernel level or hardware level. Whenever a DV/ miniDV/ HDV camcorder is plugged in and is recognized as such by the ieee1394 base driver (which needs the ohci1394 underneath), ieee1394 emits a hotplug event which should cause raw1394 be loaded automatically. raw1394's insertion should cause udev to create the /dev/raw1394 file, and at least that latter part apparently works for you. 9. Also realize you must have special privileges in order to access the device, which are not granted to you by default. 10. Grant yourself some privileges, or simply run the video editing application as root (via gksu). It is policy in Ubuntu to grant only the root user access to the /dev/raw1394 file. Most other distributions which provide the raw1394 driver grant every user in a video group or something like that access to /dev/raw1394. This is because of security concerns of the Ubuntu maintainers; see bug 6290. However, there is light at the end of the tunnel since we are getting new firewire drivers into shape which will allow distributors to implement finer grained access policies. The new drivers don't use a single device file for all devices but a file for each FireWire node (e.g. one for the controller, one for a plugged-in camera...). There appear to be Jaunty test kernel packages which have the new drivers enabled in parallel to the old ones for advanced users to try them. See also bug 276463 (driver migration) and bug 311804 (libraw1394 migration; libraw1394 v2 is required to freely switch between old drivers and new drivers, libraw1394 v2.0.1 enables fine-grained access permission policy). a. You'll manage to start capturing video, and hope you wont drop any frames which is rarely the case, as usually several frames are dropped every now and again due to buffer underruns (what the...??) even in no encoding capture mode (raw). So there are problems during FireWire I/O or related to disk I/O. There is DMA enabled for the harddisk, right? (hdparm -i /dev/... lists available and currently active DMA modes. It is highly likely that the kernel did enable DMA properly.) b. You'll still get a No camera found error, which truely I'm in the dark as to why. Could be the same as http://sourceforge.net/tracker/?func=detailatid=114103aid=2492640group_id=14103 https://bugzilla.redhat.com/show_bug.cgi?id=449252 https://bugzilla.redhat.com/show_bug.cgi?id=477279 http://sourceforge.net/mailarchive/forum.php?thread_name=7aea52800901260333i2a47825dv95a838cad3e5ee90%40mail.gmail.comforum_name=kino-dev Do you have a Panasonic or Samsung camcorder? It could presumably also happen with other camcorders though; it's just that we only discovered the nature of the problem and its solution very recently. What I expected to happen, since things should 'just work', is that once I plug in a camcorder to the 1394 jack, I'll get a popup window asking me if I want to capture video from the device. Yes, that would be good to have. Would have to be implemented in Gnome and/or KDE. I don't know, maybe there is already integration of this sort between kernel -- KDE 4-- kdenlive. (kdenlive is in active development, while kino is retired to low maintenance mode.) I also expect that a simple user, using the computer, wont need to meddle with privileges, in order to get the actual device working for them, That's, as mentioned, mostly a Ubuntu-specific problem, to be fixed in the short term by the user himself and in the long term by switching to the new drivers with more flexible permissions policy. Ironically, the new drivers are sponsored by Red Hat. Good for all Linux users but regarding the /dev/raw1394 issue especially good for Ubuntu users. and will be able to make simple home movie DVDs easy, using some simple editing tool (KINO?) out-of-the-box. DV capture does actually work out-of-the-box for quite a lot of people, besides the missing pop-up dialogue when a camera was plugged in, and besides Ubuntu's bug 6290. -- raw1394 DV sampling should work out-of-the-box https://bugs.launchpad.net/bugs/300239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
First of all, thank you for the reply. Now, from what I understand, the main
issue is what I thought it was - a policy
defect in Ubuntu, regarding the IEEE1394 devices, which would suggest this is
truely a bug, as the policy contradicts
what Ubuntu claims: it doesn't just work.
Whenever a DV/ miniDV/ HDV camcorder is plugged in and is recognized as such
by the ieee1394 base driver
(which needs the ohci1394 underneath), ieee1394 emits a hotplug event which
should cause raw1394 be loaded
automatically. raw1394's insertion should cause udev to create the
/dev/raw1394 file, and at least that latter part
apparently works for you.
Well, the last part maybe does, but I still need to manually modprobe
raw1394...
There appear to be Jaunty test kernel packages which have the new drivers
enabled in parallel to the old ones for
advanced users to try them. See also bug 276463 (driver migration) and bug
311804 (libraw1394 migration;
libraw1394 v2 is required to freely switch between old drivers and new
drivers, libraw1394 v2.0.1 enables
fine-grained access permission policy).
Yeah, but keeping in mind that I'm trying to look at it from a simple home
user's point-of-view, this isn't really a valid
solution for me. As a home user, I just downloaded the latest Ubuntu release,
and tried to use it. A simple user
wont go off and install a beta version of the distribution, which runs a test
kernel. I personally can do it, but that's not
what this bug is about. This bug is about usability and a false promise.
So there are problems during FireWire I/O or related to disk I/O. There is
DMA enabled for the harddisk, right?
(hdparm -i /dev/... lists available and currently active DMA modes. It is
highly likely that the kernel did enable DMA
properly.)
Just to play on the safe side:
# $ hdparm -i /dev/sdb
#
# /dev/sdb:
#
# Model=WDC WD2500KS-00MJB0 , FwRev=02.01C03, SerialNo=
WD-WCANK2699819
# Config={ HardSect NotMFM HdSw15uSec SpinMotCtl Fixed DTR5Mbs FmtGapReq }
# RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
# BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=?1?
# CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168
# IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
# PIO modes: pio0 pio3 pio4
# DMA modes: mdma0 mdma1 mdma2
# UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
# AdvancedPM=no WriteCache=enabled
# Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
#
# * signifies the current active mode
Do you have a Panasonic or Samsung camcorder? It could presumably also happen
with other camcorders
though; it's just that we only discovered the nature of the problem and its
solution very recently.
Nope, it's a Canon MV800 camcorder.
In closing, I'm sure this will be fixed at the driver level, and maybe the new
driver will enable Ubuntu to actually
live up to that promise they made, and things will just work. I know it's
impossible to test every single configuration
available. I just expect more than a false promise. If they posted a list of
devices one can use, that will actually just
work, that would have been great. Alas, from what you said, I'm sure that at
least up to version 8.10, that list
would be empty for Ubuntu users who're interested in using their camcorders,
cause as you mentioned, this is a
policy issue.
I guess that popup thingy suggestion should be posted as a feature request, but
since I'm using Gnome, and
since Kino and Kdenlive are both oriented towards KDE, I'm not sure this
feature will find takers on Gnome. Will
think about it.
-- Liad Weinberger.
--
raw1394 DV sampling should work out-of-the-box
https://bugs.launchpad.net/bugs/300239
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
