|
Firewire Saga Summary Getting firewire to work involved installing a large number of libraries, including development versions. Everything built fine and both dvgrab and kino are working fine. However, I couldn't get dvcont to work and gave up on gscanbus because it appears to require older versions of libraries that form part of the SuSE distro -- which I'd rather not mess with. You can do without a tape transport controller -- use your hands -- or you can wait until the current projects are mature. dvgrab may well just incorporate dvcont for instance. 2.4.16 seems to be a good kernel for firewire and there's no hurry to upgrade to the more recent kernels. (For the kernel saga, see here.) when 2.5 stabilizes, you can move to that. Installation history 1. Installed libraw1394 from Sourceforge. I used the rpm and SuSE packager took it without complaining. 2. I downloaded dvgrab and tried ./configure. It got to libraw1394 and didn't find it, so aborted. 3. I tried to test libraw with the command testlibraw, and got the error message "couldn't get handle: No such file or directory This probably means that you don't have raw1394 support in the kernel or that you haven't loaded the raw1394 module." 4. Then I tried a command to see if the Firewire module was loaded: lspci gave the result (among other things):
00:0b.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 4d69 (rev 02) 00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815 00:11.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 OHCI Compliant IEEE-1394 Controller 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo Banshee (rev 03) Now, for the recent installation, this is useful as it documents the PCI storage controller is installed but "unknown", and that the Voodoo Banshee controller seems to be working well (in fact, my monitor is behaving excellently). As for the Firewire card, it is a TI OHCI Compliant card and is working fine. Does that mean I need a raw1394 module? Maybe -- and maybe not. 5. I discovered from my previous installation that I had to define nodes for raw1394 and video1394 and did so:
mknod /dev/video1394 c 172 0 chmod a+rw /dev/video1394 mknod /dev/raw1394 c 171 0 chmod a+rw /dev/raw1394 No protests here; this just worked, with no response either. 6. I then tried testlibraw again, and now it worked -- so I obviously have it in the kernel as I thought (this is the 160GB-patched 2.4.16p kernel):
gubbio:/usr/bin # testlibraw successfully got handle current generation number: 2 1 card(s) found nodes on bus: 1, card name: ohci1394 using first card found: 1 nodes on bus, local ID is 0, IRM is 0 doing transactions with custom tag handler trying to send read request to node 0... completed with value 0x4119e91c
using standard tag handler and synchronous calls trying to read from node 0... completed with value 0x5898e91c testing FCP monitoring on local node got fcp command from node 0 of 8 bytes: 01 23 45 67 89 ab cd ef got fcp response from node 0 of 8 bytes: 01 23 45 67 89 ab cd ef polling for leftover messages This is all very encouraging: it finds the card, the bus node, the card name, and it tests fine. 7. However, ./config dvgrab still doesn't find libraw1394. This is likely because it's looking in the wrong place -- I need to add a directory to the list of libraries it checks, or I need to add a line to the configuration command. Now, this is the frustrating problem I ran up against last time too: I can't find things. I install them and have no idea where they went. So there are a number of tools to handle this, and you need them. First, you simply need to have a way of finding files. The command find should do it, so learn it. You can also use diff before and after an installation of an rpm file -- or another file -- but you need to learn the syntax for that whole command. Second, you can look at /etc/ld.so.conf which contains a list of library directories -- presumably ./configure looks at this file. You can add lines to this file, and then run ldconfig, which will update the list of library files (where is that list?). The current list contains these entries:
gubbio:/usr/bin # more /etc/ld.so.conf /lib-aout /usr/X11R6/lib/Xaw95 /usr/X11R6/lib/Xaw3d /usr/X11R6/lib /usr/i486-linux/lib /usr/i486-linux-libc5/lib=libc5 /usr/i486-linux-libc6/lib=libc6 /usr/i486-linuxaout/lib /usr/i386-suse-linux/lib /usr/local/lib /usr/openwin/lib /opt/kde/lib /opt/kde2/lib /opt/gnome/lib So, first: the find command. You just need to find where libraw is. I found some hints online and cobbled together this command:
find / -iname *libraw* -mount -print | less which set the system churning as desired. -iname means case-insensitive, -mount means don't search other harddrives, -print means show me the results, and then it's piped to less. Here is the only result: /usr/bin/testlibraw Wow! Now try the same for raw1394. Now the result came up at once, suggesting the whole file system is currently in memory. The result was impressive:
/lib/modules/2.4.10-4GB/kernel/drivers/ieee1394/raw1394.o /root/.kde2/share/apps/kio_http/cache/s/sourceforge.net_projects_libraw1394:2947cb5f /root/.kde2/share/apps/kio_http/cache/d/download.sourceforge.net_libraw1394_:1df5bb7e /root/.kde2/share/apps/kio_http/cache/d/download.sourceforge.net_libraw1394_:180ac16b /root/.kde2/share/apps/kio_http/cache/d/download.sourceforge.net_libraw1394_:19c3f87d /root/.kde2/share/apps/kio_http/cache/c/cvs.sourceforge.net_cgi-bin_viewcvs.cgi_libraw1394_:34e5f55 /root/.kde2/share/apps/kio_http/cache/c/cvs.sourceforge.net_cgi-bin_viewcvs.cgi_libraw1394_libraw13 /root/.kde2/share/apps/kio_http/cache/c/cvs.sourceforge.net_cgi-bin_viewcvs.cgi_libraw1394_libraw13 /root/.kde2/share/apps/kio_http/cache/c/cvs.sourceforge.net_cgi-bin_viewcvs.cgi_libraw1394_libraw13 /root/.kde2/share/apps/kio_http/cache/c/cvs.sourceforge.net_cgi-bin_viewcvs.cgi_libraw1394_libraw13 /root/.kde2/share/apps/kio_http/cache/p/prdownloads.sourceforge.net_libraw1394_libraw1394-0.9.0-1.i /root/.kpackage/libraw1394-0.9.0-1.i386.rpm /usr/lib/libraw1394.so /usr/lib/libraw1394.so.5 /usr/lib/libraw1394.so.5.0.0 /usr/share/doc/libraw1394-0.9.0 /usr/src/linux-2.4.10.SuSE/drivers/ieee1394/raw1394.c /usr/src/linux-2.4.10.SuSE/drivers/ieee1394/raw1394.h /usr/src/linux-2.4.16/drivers/ieee1394/raw1394.c /usr/src/linux-2.4.16/drivers/ieee1394/raw1394.h /usr/src/linux-2.4.16/drivers/ieee1394/raw1394.o /dev/raw1394Note that the first is a module and the next five cache -- kde keeps its own cache apparently. Then you get the libraries in /usr/lib/, which amazingly is not included in /etc/ld.so.conf -- so you can add it. You also have one in /usr/share/doc/, which also is not included -- not clear if you need both. Next, you find raw1394 in the kernel source, and the recently defined node. All this was very reassuring and I now know find. The trick is the / and the -mount and -print and | less -- frankly, this is more than most users want to deal with a clearly the stench of unix. So try first to add /usr/lib to /etc/ld.so.conf and run ldconfig and then ./config dvgrab to see it that works. No luck -- ./configure dvgrab stops at the same place, so you haven't fixed the problem. The error message is interesting:
checking for libraw1394/raw1394.h... no configure: error: You need raw1394 and csr headers to compile dvgrab So it says I need raw1394, which it may or may not be finding, and also raw1394.h -- a header file. Now, interestingly the search finds the header file, but it's in the kernel source, as above:
/usr/src/linux-2.4.16/drivers/ieee1394/raw1394.h Where does dvgrabexpect to find it? Should I copy this header file to some other location? This seems plausible. I do a vi on the dvgrab configure file to inspect it. Right at the top I find this: # Defaults: ac_help= ac_default_prefix=/usr/local # Any additions from configure.in: ac_help="$ac_help --enable-debug include debugging symbols in binaries" ac_help="$ac_help --with-libraw-includes=PATH Path where libraw1394 headers are installed" ac_help="$ac_help --with-libraw-libs=PATH Path where libraw1394 library is installed" These are appearently read from configure.in -- so I inspect that too; it begins by saying " Process this file with autoconf to produce a configure script." So I may need to run autoconf first, and that could solve the problem. It looks like you should be able to run autoconf with variables to give it the necessary information, as it says, Checks for libraries. AC_ARG_WITH(libraw-includes, [ --with-libraw-includes=PATH Path where libraw1394 headers are installed]" So presumably you could run autoconf --with-libraw-includes=/usr/src/linux-2.4.16/drivers/ieee1394/ --with-libraw-libs=/usr/lib/ Actually, no, autoconf doesn't take flags like that -- I get "invalid option --with-libraw-includes=/usr/src/linux-2.4.16/drivers/ieee1394/" -- and a simple invoking of autoconf didn't produce any results -- ./configure still stalls at the same place. So we'll try:
./configure \ --with-libraw-includes=/usr/src/linux-2.4.16/drivers/ieee1394/ \ --with-libraw-libs=/usr/lib/ This command is accepted, but produces no effects: you get the same error,
checking for libraw1394/raw1394.h... no configure: error: You need raw1394 and csr headers to compile dvgrab Next, you could try to edit configure.in directly -- I looked but couldn't find a plausible place to include the information; it clearly seems to need these values passed as parameters from the command line. Next, try copying the header file to some other place. A comment online http://rpmfind.net/linux/RPM/mandrake/8.1/contrib/RPMS/libraw1394_5-devel-0.9.0-2mdk.i586.html suggests either /usr/include or better /usr/include/libraw1394 It's pretty clear that the rpm version of libraw does not provide the files dvgrab is looking for. You could back up and try the tarball instead -- but it may be worth trying to copy over the header file first; it can't hurt. So I do:
cp /usr/src/linux-2.4.16/drivers/ieee1394/raw1394.h /usr/include This makes not difference; ./configure dvgrab doesn't find it. I then try one final
./configure --with-libraw-includes=/usr/include --with-libraw-libs=/usr/lib/ No luck. All of this has had zero effect on the compilation process -- I've learned a few things, but nothing solves the problem. My next attempt is to install the libraw1394-devel package; I think this is what made things work last time. In fact, it's from instructions for a libraw1394-devel (see above) that I found information about where headers should go. The files mentioned include:
/usr/include/libraw1394 /usr/include/libraw1394/csr.h /usr/include/libraw1394/ieee1394.h /usr/include/libraw1394/raw1394.h /usr/lib/libraw1394.a /usr/lib/libraw1394.la /usr/lib/libraw1394.so Note the csr.h file -- this is obviously the csr header file that dvgrab needs. Interestingly, this is included in the kernel source:
/usr/src/linux-2.4.16/drivers/ieee1394/csr.h However, this may be the ieee1394 csr header and not the libraw csr header -- the file libraw1394.a for instance does not exist, nor does libraw1394/csr.h. It seems plausible that these are the files dvgrab is looking for. Note, incidentally, the files found by the previous search (above) in the kernel source files:
/usr/src/linux-2.4.16/drivers/ieee1394/raw1394.c /usr/src/linux-2.4.16/drivers/ieee1394/raw1394.h /usr/src/linux-2.4.16/drivers/ieee1394/raw1394.o These are raw1394 files, not libraw1394 files. Therein may lie the crux of the installation protest. So remove the header you copied and add the -devel rpm. I get it from http://download.sourceforge.net/libraw1394/libraw1394-devel-0.9.0-1.i386.rpm and have to download it first, as I did the first time. I downloaded it to the desktop and clicked on it; packager opened and it installed fine. Now, the find command
find / -iname *raw1394* -mount -print | less shocking produces only this: /usr/include/libraw1394 Note that this is the directory you wanted -- but it's not the only thing you expected to see. The fact that this directory has been created is great news (i.e., what you were expecting to accomplish), but why isn't find listing all the other instances? Surely they have not been removed? Well, I discovered that the / swich in find simply refers to the current directory. So to find all files, you need to be in / yourself. Searcing from / you get (removing the modules, cache, RecentDocuments, rpms, and kernel sources):
/usr/lib/libraw1394.so /usr/lib/libraw1394.so.5 /usr/lib/libraw1394.so.5.0.0 /usr/share/doc/libraw1394-0.9.0 /dev/raw1394
/usr/share/aclocal/libraw1394.m4 /usr/include/libraw1394 /usr/include/libraw1394/raw1394.h Compare this with what you had:
/usr/lib/libraw1394.so /usr/lib/libraw1394.so.5 /usr/lib/libraw1394.so.5.0.0 /usr/share/doc/libraw1394-0.9.0 /dev/raw1394 That's really just three new files:
/usr/share/aclocal/libraw1394.m4 /usr/include/libraw1394 /usr/include/libraw1394/raw1394.h Compare that with what the Mandrake distro promised:
/usr/include/libraw1394 /usr/include/libraw1394/csr.h /usr/include/libraw1394/ieee1394.h /usr/include/libraw1394/raw1394.h /usr/lib/libraw1394.a /usr/lib/libraw1394.la /usr/lib/libraw1394.so You get a header file, but no /libraw1394/csr.h file. Actually, a further find command shows that to be false; the file /usr/include/libraw1394/csr.h has been generated. Because it does not have libraw in its name, the find command obviously didn't list it. libraw1394.a however has not been generated, nor was libraw1394.la. Instead, you get .so.5 and .so.5.0.0, which might be much the same thing. On the whole, it looks like the problem was simply that you needed the development rpm and all this careful sleuthing was strictly speaking unnecessary, though very educational. Indeed, configure dvgrab now went without a hitch. So you know this for next time! I then did a painless make and a make install, which reports:
/bin/sh ./mkinstalldirs /usr/local/bin /usr/bin/install -c dvgrab /usr/local/bin/dvgrab So it installs in /usr/local/bin. Last time I had to move it to /usr/bin, but this time it starts up fine. I don't try to do anything with it before installing gscanbus. Note that dvgrab installs very simply -- it should only take a minute to get libraw1394 and libraw1394-devel. All the other stuff was newbie delays. gscanbus. I got the 0.7.1 version I used before as a tarball. Now, gscanbus finds libraw, but not gtk:
checking for gtk-config... no checking for GTK - version >= 1.2.0... no *** The gtk-config script installed by GTK could not be found *** If GTK was installed in PREFIX, make sure PREFIX/bin is in *** your path, or set the GTK_CONFIG environment variable to the *** full path to gtk-config. configure: error: gscanbus needs GTK I have version 1.2.10-101 according to packager, so here's another challenge: do I just need to tell it where the library is located, or do I need the -devel version? Of course, now I know how to find things, and the command gubbio:/ # find / -iname gtk -mount -print | less produced 32 results:
/etc/gtk /usr/lib/gtk /usr/lib/rep/i686-suse-linux-gnu/gui/gtk /usr/share/doc/packages/gtk /usr/share/themes/Default/gtk /usr/share/themes/Metal/gtk /usr/share/themes/Notif/gtk /usr/share/themes/Pixmap/gtk /usr/share/themes/Raleigh/gtk /usr/share/themes/Redmond95/gtk /usr/share/themes/4Missy/gtk /usr/share/themes/AbsoluteS/gtk /usr/share/themes/Adept/gtk /usr/share/themes/Alchemy/gtk /usr/share/themes/Alpha2/gtk /usr/share/themes/Aqua/gtk /usr/share/themes/AquaX/gtk /usr/share/themes/Arctic-Pixmap/gtk /usr/share/themes/Astronique-2/gtk /usr/share/themes/AzTecha/gtk /usr/share/themes/AzureGold/gtk /usr/share/themes/BeBox/gtk /usr/share/themes/Beos-4.5/gtk /usr/share/themes/Birth/gtk /usr/share/themes/BlueCOSM/gtk /usr/share/themes/BlueGradient/gtk /usr/share/themes/BlueIce/gtk /usr/share/themes/BlueStripes/gtk /usr/share/themes/Descarga/gtk /usr/share/themes/DreamWorks/gtk /usr/share/themes/E-efm-GTK+/gtk /usr/share/themes/Ecosm-Theme/gtkThe short answer here is simple: gtk is in /usr/lib/gtk. Now, as you see above, I just added /usr/lib to the /etc/ld.so.config file, which now has:
/usr/lib /lib-aout /usr/X11R6/lib /usr/X11R6/lib/Xaw95 /usr/X11R6/lib/Xaw3d /usr/i486-linux/lib /usr/i486-linux-libc5/lib=libc5 /usr/i486-linux-libc6/lib=libc6 /usr/i486-linuxaout/lib /usr/i386-suse-linux/lib /usr/local/lib /usr/openwin/lib /opt/kde/lib /opt/kde2/lib /opt/gnome/libHowever, gscanbus is not looking for the library but for the gtk-config file -- and I indeed do not have it. This is a bit tricky -- I need the gtk-config file, but SuSE may well have handled that in some other way, with a SuSE-config file. It may be better to hold off on building gscanbus until you have an LFS installation, not to mess up SuSE. Another option for controlling the camera is dvcont at http://www.spectsoft.com/idi/dvcont -- it can be put in a script with dvgrab to start and stop the camera for captureing. A third option is Coriander at http://www.tele.ucl.ac.be/PEOPLE/DOUXCHAMPS/ieee1394/coriander/ -- this is a GUI to control a digital camera using the libdc1394 library. Coriander is clearly superior to both dvcont and gscanbus, but dvcont has the attraction of being a command-line controller that should be enough to get you going, and may not require much in terms of libraries. See his website for a list of the commonsense commands: At the console prompt type:
$ dvcont <command> [ENTER] -- WHERE <command> is one of the following:
play - make the camera play (or toggle slow-mo if already playing) stop - stop the camera (stops all actions) rewind - rewind the camera (or rewind-play if playing) ff - fast forward the camera (or ff-play if playing) pause - toggle pause (play or record) record - start recording ( ** THIS DOES NOT GIVE ANY NOTICE ** ) eject - ejects the tape (very cool to do across the room!) version - shows the program version verbose - makes the program output debuging info. next - goto next frame (paused or stopped) prev - goto previous frame (paused or stopped) dev <number> - Set the device number in the chain. (use before any other command.. except verbose)However, the dvcont installation is unintelligible for me -- the programmer assumes you know programming. I get "nothing to be done for 'all'", which is the configuration line in Makefile. You can e-mail the author Jason Howard <jason@spectsoft.com> and ask how to get past this obstacle. As for Coriander, it's being actively developed by Damien Douxchamps, with a new version today (29 December 2001). He writes, "Version 0.21 will be posted soon. It will be the last to use Xv and GDK explicitely: later versions will use SDL instead. This should not be a big deal since SDL includes Xv and GDK was not working in multithreaded programs anyway." This makes me think I should hold off until the new SDL (Simple DirectMedia Layer, http://www.libsdl.org/) version is ready. Note, incidentally, that SDL runs on *nix and OS X!
Development Dan Dennedy, the libavc1394 maintainer, writes about the new dv1394 device driver on 11 December 2001 at Arne Schirmacher's discussion site at http://www.schirmacher.de/dcforum/DCForumID2/76.html "dv1394 testers needed" dv1394 is a new protocol driver now available in linux1394 CVS HEAD. dv1394 encapsulates and refines much of our accumulated knowledge about DV reception and transmission over 1394. It has a frame-oriented API that is simpler to use than the current packet-oriented ones. Until now, DV transmission required some application logic on top of video1394 that is currently in Kino and dvconnect. This is now in dv1394, and someday dv1394 will replace the use of raw1394 and video1394 for all DV I/O. After compiling and loading the module... 1. create a dv1394 device file if you are not using devfs: % mknod -m 666 /dev/dv1394 c 171 32 2. if you are using PAL, set it to PAL mode: % echo format=PAL >/proc/ieee1394/dv/0 verify: % cat /proc/ieee1394/dv/0 3. start camera playback: % dvcont play 4. capture DV: % cat /dev/dv1394 >test.dv 5. stop camera: % dvcont stopSummary of Digital Video for Linux. There is development on the basic interface (dv1394 by Dan Dennedy), on the capture front (mainly Coriander), and on the compression front (mainly Transcode). The confluence of Mac OS X and *nix is starting to be felt. You already have a stable installation now and know how to recompile the kernel. You should focus on the following: * See if dvgrab works -- you don't really need to control the camera remotely. * Install kino, which worked fine before. Kino I verified that I had the audiofiles, esound, gppshare, gtk, imlib, and xshared packages. Kino wants gnlibs and gnlibs-devel -- these are now called gnome-libs (I have 1.4.1.1-31) and gnome-libs-devel, which you don't have. I downloaded it but came across three dependency problems:
Dependency Problem: gtk-devel is needed by gnome-libs-devel-1.4.1.1-72 orbit-devel is needed by gnome-libs-devel-1.4.1.1-72 imlib-devel is needed by gnome-libs-devel-1.4.1.1-72 Gtk-devel in turn had a problem:
Dependency Problem: glib-devel is needed by gtk-devel-1.2.10-125 Now, glib-devel 1.2.10-102 rpm installed fine, and once that was in place, so did gtk-devel 1.2.10.125. Next to orbit-devel --
Dependency Problem: indent is needed by orbit-devel-0.5.8-71 Indent 2.2.6-115 installed fine, and then so did orbit-devel. Next to imlib-devel -- version 1.9.10-97 installed fine. Once these three were in place, gnome-libs-devel version 1.4.1.1-72 installed fine. Now, kino also reportedly wants shlibs, which are "The shared C libraries libc.so and libm.so (old version 5)". Now, I used find to discover that I already have /usr/lib/libc.so and /usr/lib/libm.so, so I'll assume this is already taken care of. Finally, I need the 1394 libraries. I already have libraw1394-0.9, but I still need: libdv-devel-0.9-1.i386.rpm libdv-0.9-1.i386.rpm libavc1394-0.3.0.tar.gz The links to these can be found on kino's homepage at http://www.schirmacher.de/arne/kino/kino_hwsw_e.html -- I got the libdv-devel rpm first, and it installed fine. The libdv rpm protested: "Dependency Problem: libdv.so.1 is needed by libdv-0.9-1" -- now that's a curious one. Surely this file is generated by the installation. Now, libdv is the Quasar DV Codec (http://libdv.sourceforge.net/) by Charles 'Buck' Krasic and Erik Walthinsen -- grad students in Oregon (Erik is now employed). I get exactly the same error message if I try to install from Sourceforge. The dependency bug existed already in June -- I unchecked "check dependencies". I could try to build it from scratch I guess, but it's not clear this is serious. Now, there's a patch that's likely for this problem at http://sourceforge.net/tracker/index.php?func=detail&aid=422421&group_id=4393&atid=304393 by Krasic himself; I didn't use it, but you could go there if you have problems. Unfortunately it doesn't look like anyone is actively working on this project. Finally, libavc1394 is at http://sourceforge.net/projects/libavc1394/ -- version 0.3.1 is from late September. Here, the configuration went without a hitch, as did make and make install -- the latter giving the usual Libraries have been installed in: /usr/local/lib
If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages.Now, /etc/ld.so.conf includes /usr/local/lib, so I should be fine. I wonder what "libtool" is? You should learn how to use flags -- this should be learned from the LFS project! A mix of these things is actually not bad -- I mean installing for real and using LFS instructions for play, as it were. In any case, libavc1394 should be installed, and this should be all that kino needs. Note in general that if there's a request for header files, this very straightforwardly means that you need the -devel version. Now for kino. I get the 19 November 2001 version, or 0.5. Arne has worked on it steadily for about a year by now, and is still doing stuff. Now, kino stopped at this:
checking for xml2-config... no configure: error: Could not find xm2-config I have libxml2, version 2.4.3-25 -- however, I don't have the config file and probably need xml2-devel. That installed fine. I should mention that all along here I'm using SuSE's professional package list at http://www.suse.com/en/products/suse_linux/i386/packages_professional/ to find the location of the packages and then the SuSE mirror at ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/suse/i386/7.3/suse/ to get them. Click on them and the packager starts up; it takes seconds. I try ./configure again and it works! dvgrab and kino are high quality products -- and obviously Dan Dennedy knows what he's doing too. Make works fine for a while until this:
/usr/i486-suse-linux/bin/ld: cannot find -lesd I vaguely remember this is an error message that means you need esound-devel -- cf. http://mail.gnome.org/archives/gnumeric-list/2001-June/msg00008.html -- I get it and it installs fine. When I again type make, it doesn't restart but finishes quickly -- it could mean there'll be a problem, but we'll try it. When I try to start kino, I get an error message: "kino: error while loading shared libraries: libavc1394.so.0: cannot open shared object file: No such file or directory." Now, libavc1394 installed without protest and in fact /usr/local/lib/libavc1394.so.0 is present. I start by making a clean install of kino -- delete the installation directory (but not the installed files), download the tarball again, and configure. I notice a warning during configure:
-I/usr/include/libxml -c framedisplayer.cc framedisplayer.cc: In method `void FrameDisplayer::Put(Frame &, GtkWidget *, int)': framedisplayer.cc:108: warning: enumeration value `DISPLAY_NONE' not handled in switch framedisplayer.cc:108: warning: enumeration value `DISPLAY_BGR' not handled in switch framedisplayer.cc:108: warning: enumeration value `DISPLAY_BGR0' not handled in switch framedisplayer.cc:108: warning: enumeration value `DISPLAY_RGB16' not handled in switch Such warnings indicate some type of reduced functionality; unclear whether these particular ones matter. After the reinstallation, I get exactly the same error message. I try to run ldconfig -- it's honestly the one thing I do -- and Kino works! Wow, that's a lesson. Now, Kino actually works, and when I turn on the camcorder, the image turns up on the screen! I don't have to be grabbing -- I can watch it straight from the camcorder. After quite some time, "DCR-TRV-900" appears in the "Setup" screen -- this is simply an autodetect feature, and it works! However, it doesn't help me -- the purpose is supposed to be to control the tape transport mechanism, but this is I guess not yet implemented, or requires dvcont as a plugin. You can, however, use Kino to grab. First, it hangs when I press the record button, after having started -- or failed to start -- the camcorder. It turns out I had wound the tape to the end instead of rewinding. I get it started again and start to capture. In Setup, I chose "preview while capturing" -- this somehow triggers runlevel 5 (for some weird reason I now start in runlevel 4, which I'm quite happy with), which starts KDE and cuts off everything I was doing.
|
|
|||||
|
|
|
|
|
|
|
|
|||||
