Brett, Thanks for your help. One way or another it finally started working. I don't know yet whether it will survive a reboot. I'll probably do that test later this evening or tomorrow but at least I'm finally getting v4l devices.
I think it was most likely a combination of not using the existing tarball (whatever and whereever that is!) and then running the right drivers. Even after rebooting the dev/v4l devices weren't there, but then when I started running some programs that try to use them they suddenly showed up. All I hope for now is that they don't suddenly disappear! Anyway, thanks for the ideas. cheers, Mark On 5/22/05, Brett I. Holcomb <[EMAIL PROTECTED]> wrote: > Try the tarball no. It may be using the old devfs tarball. > > On Sun, 22 May 2005, Mark Knecht wrote: > > > On 5/22/05, Brett I. Holcomb <[EMAIL PROTECTED]> wrote: > >> Okay. That's not it. Here's what I have in /etc/conf.d/rc that pertains > >> to udev/devfs. I assume you have RC_DEVFSD_STARTUP set to no but what > >> about the tarball? > >> > >> # Set to "yes" if you want to save /dev to a tarball on shutdown > >> # and restore it on startup. This is useful if you have a lot of > >> # custom device nodes that udev do not handle/know about. > >> # (ONLY used by UDEV enabled systems!) > >> > >> RC_DEVICE_TARBALL="no" > >> > >> # Set to "yes" if you want devfsd to start upon bootup. This is > >> # the default for Gentoo. > >> # Set to "no" only if you understand the full implications. A > >> # number of files may need to be altered (i.e. /etc/inittab, > >> # /etc/fstab, etc.). > >> # Also note that it does _NOT_ start for UDEV enabled systems, > >> # even if RC_DEVFSD_STARTUP="yes" ... > >> > >> RC_DEVFSD_STARTUP="no" > >> > > Brett, > > My /etc/conf.d/rc file looks a bit different but good enough I > > hope. I do not have a variable called RC_DEVFSD_STARTUP. None the less > > I've rebuilt the kernel yet again (5th time today?) completely > > removing devfs and even with these settings I am not getting /dev/v4l > > devices: > > > > # Use this variable to control the /dev management behavior. > > # auto - let the scripts figure out what's best at boot > > # devfs - use devfs (requires sys-fs/devfsd) > > # udev - use udev (requires sys-fs/udev) > > # static - let the user manage /dev > > > > #RC_DEVICES="auto" > > RC_DEVICES="udev" > > > > # UDEV OPTION: > > # Set to "yes" if you want to save /dev to a tarball on shutdown > > # and restore it on startup. This is useful if you have a lot of > > # custom device nodes that udev does not handle/know about. > > > > RC_DEVICE_TARBALL="yes" > > > > udev is starting and the messages at boot time look OK to me. > > > > I'm thinking I must somehow be barking up the wrong tree. I do not > > understand the udev language but it would seem that it cannot be that > > difficult. Why are there no v4l devices? > > > > # v4l devices KERNEL="video[0-9]*", NAME="v4l/video%n", > > SYMLINK="video%n", GROUP="video" > > KERNEL="radio[0-9]*", NAME="v4l/radio%n", GROUP="video" > > KERNEL="vbi[0-9]*", NAME="v4l/vbi%n", SYMLINK="vbi%n", GROUP="video" > > KERNEL="vtx[0-9]*", NAME="v4l/vtx%n", GROUP="video" > > > > The rules do not seem to be the problem. They are standard in the > > rules file. Therefore there must be something not happening to cause > > them to get invoked, or possibly something that did happen taht caused > > them to be invalid. > > > > Problem is I don't have a clude what makes this happen? Why do any of > > these get involed in the first place? Is there some caracter device I > > need to create to make them happen the first time? I haven't found > > evidence of that in the wiki's but maybe I've missed it. > > > > Thanks much, > > Desperately Mark > > > > > > -- > > Brett I. Holcomb > [EMAIL PROTECTED] > Registered Linux User #188143 > Remove R777 to email > -- > gentoo-user@gentoo.org mailing list > > -- gentoo-user@gentoo.org mailing list
