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 HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs 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

Reply via email to