[PlanetCCRMA] How do I get DV to work with Planet kernel?

[Mark Knecht]

Jim,
   Hi. I was working with someone on the 1394 developers side yesterday to
come up with a standard set of instructions for doing CDRW stuff. It should
apply as a starting point to what you're attempting to do. Here's the best
parts of our instructions right now, but I haven't gone through and tested
them by hand:

<SNIP>
That would be
  insmod ieee1394
  insmod ohci1394    # assuming it is an OHCI adapter
  insmod sbp2
  insmod raw1394     # optional, e.g. for gscanbus

However, there is no point in using insmod. It is just needed in
development, or if something is seriously broken. Modprobe is not
only more convenient than insmod, it helps to avoid errors too.

So forget about insmod is even existing, and do this instead:

  modprobe ohci1394  # also loads ieee1394
  modprobe raw1394   # optional
  modprobe sbp2      # also loads scsi_mod

Or

  modprobe ohci1394 && modprobe sbp2

It does not matter if the SCSI stuff which sbp2 depends on is
hard-linked into the kernel or separated as modules. Parts of
IEEE 1394 can stay in the kernel too, but I strongly recommend to
use modules for 1394.

The "modprobe sbp2" is not necessary if the kernel is hotplug
enabled and the userland tools for hotplug are in place,
especially /etc/hotplug/ieee1394.agent.

Then we have to help the SCSI subsystem a bit. There is a
sinister mystery about Linux' SCSI that has it is still lacking
real hotplug support, even if it is widely (if not primarily)
used for various kinds of genuinely hotpluggable hardware ---
USB, parport junk, Firewire. (Even the real parallel-SCSI
hardware can be hotplugged but was not originally intended for
that). Back to the topic: At the moment the sbp2 driver is loaded
it will announce all attached SBP-2 devices to Linux' SCSI
subsystem, but not subsequent additions or removals. We have to
run e.g. "rescan-scsi-bus.sh -r" each time a device is added or
removed.


>    After having done that, then what does he have to do to get the SCSI
> support working for CDROMS? Does he have to insmod something?

The drivers needed for that are, again, loaded automatically
nowadays. Module name, purpose, device files:
sd_mod     harddisks                      /dev/sd*
sg         generic (CD-R/W, scanners...)  /dev/sg*
sr_mod     CD-/DVD-ROM                    /dev/scd* or /dev/sr*
st         tape drives                    /dev/st[01]* I guess

The device file names are of course different if devfs is in use.

Good luck,
Mark

-----Original Message-----
From: planetccrma-admin@ccrma.Stanford.EDU
[mailto:planetccrma-admin@ccrma.Stanford.EDU]On Behalf Of Fernando Pablo
Lopez-Lezcano
Sent: Monday, October 21, 2002 10:14 PM
To: Jim Ruxton
Cc: planetccrma@ccrma.Stanford.EDU
Subject: Re: [PlanetCCRMA] How do I get DV to work with Planet kernel?


> I'm trying to get DV to work. I installed the DV related rpm's from
> Planet CCRMA. I then tried to reconfigure my kernel (2.4.19-1.ll) using
> xconfig but the IEEE 1394 option was greyed out. Any suggestions on how
> I can get DV up and running using the planet kernel.

You do not need to reconfigure or rebuild the kernel at all, it already
has the modules necessary to handle ieee1394 (at least for ohci compliant
chipsets). You will need to create two devices in /dev:

  mknod /dev/video1394 c 172 0
  mknod /dev/raw1394 c 171 0

(and of course make sure that the user who is going to deal with them has
access to both devices)

Then load the kernel modules that deal with ieee1394:

  /sbin/modprobe raw1394
  /sbin/modprobe ohci1394

You should see messages in /var/log/messages when the chipset is
recognized by the drivers. After that it is just a matter of connecting
the camcorder (more messages should appear in /var/log/messages) and
firing up, let's say, kino. Capture should work.

Hopefully I'm not forgetting something crucial.
-- Fernando

_______________________________________________
PlanetCCRMA mailing list
PlanetCCRMA@ccrma.stanford.edu
http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma