Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #7709
| From | Kevin Snodgrass <kdsnodgrass@yahoo.com> |
|---|---|
| Newsgroups | comp.os.linux.misc |
| Subject | Re: assigning specific /dev/videoN to specific USB webcams |
| Date | 2013-03-31 18:16 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <kj9ui3$7pp$1@dont-email.me> (permalink) |
| References | <ki552n$nat$1@dont-email.me> <kinsh3$2ua$2@dont-email.me> <kio081$ui1$2@dont-email.me> |
On Sun, 24 Mar 2013 22:54:57 +0000, J G Miller wrote: > On Sunday, March 24th, 2013, at 21:51:32h +0000, Kevin Snodgrass > explained: > >> I have 2 DVRs, 1 has 2 identical Hauppauge PVR-250 cards, but they are >> just straight NTSC cable > > Not changed to digital (as in digital cable) yet? Yes, but most of those channels are scrambled and I only have 1 cable box. I've had this setup since 2003/2004 except for the pcHDTV card which I added a few years ago. Giving serious consideration to purchasing an HDHomeRun Prime... >> So far, the webcam always seems to be /dev/video0, but the PVR-250 and >> the pcHDTV seem to be randomly assigned /dev/video1 and /dev/video2 > > Well probably because the kernel is probing the USB ports before it gets > on to the PCI slots where the cards are located. That makes sense, and it's also not a problem. The problem is the semi- randomness of /dev/video1 and /dev/video2. > Your problem is rather more difficult to resolve because both of your > cards are the same model. Theoretically it should be possible to create > a udev rule based on the absolute pci_path_to_device string because they > are in different slots. Actually they are different cards. The PC with 2 PVR-250 cards also has identical inputs, so which card is which does not matter. I mucked around a bit and found out that the /dev/videoX device nodes are symlinks from /dev/v4l/by-path/. Since PCI slot is part of the device node name in /dev/v4l/by-path/ it is possible to use those instead of the simpler /dev/videoX device node names. Example, on my system the PVR-250 is on PCI bus 1, slot 7, so I can access it with /dev/v4l/by-path/pci-0000 \:01\:07.0-video-index0. I.e., this works: $ mplayer /dev/v4l/by-path/pci-0000\:01\:07.0-video-index0 Since the bus/slot will not change unless I move the card I will just change my script(s) to use that instead. >> BTW, does anyone know why the pcHDTV 3000 does NOT use /dev/videoX ? >> It uses /dev/dvb/adapterX/dvrX. Is there a techinical reason why the >> device driver authors chose that instead of /dev/videoX ? > [snippage] > > So oversimplifying perhaps -- analog video devices use /dev/videoN > files, whereas digital video devices use /dev/dvb/adapterN directories. ok, but WHY does V4L assign analog devices /dev/videoX and digital /dev/ dvb/adapterX ? I guess I'm just less than impressed with the lack of consistancy. Especially since there is a /dev/videoX node associated with the pcHDTV card, but it is completely useless as far as I can tell. Therefore, what's the point? > But back on the topic of udev rules, it seems that this is not the > newgroup that has any udev gurus. > > Can anybody suggest where is the best place to get some help? And back to the semi-randomness of hardware devices and their device node names... It's irritating to me at least, that Linux is NOT consistent with device names across reboots. This causes me major issues elsewhere. My opinion, the user/sysadmin shouldn't have to write scripts to work around things like semi-random device node naming from kernel modules to achieve simple things like recording from tuner card X vs card Y or automated checking with smartctl of hard drive health. (1 machine has 4 drives, if drive 3 has some health issues, but I reboot that machine before checking the logs I create nightly, it gets assigned a different /dev/sdX name, now i don't know which drive it was that had the problem pre-reboot.)
Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
assigning specific /dev/videoN to specific USB webcams J G Miller <miller@yoyo.ORG> - 2013-03-17 19:20 +0000
Re: assigning specific /dev/videoN to specific USB webcams Robert Heller <heller@deepsoft.com> - 2013-03-17 14:46 -0500
Re: assigning specific /dev/videoN to specific USB webcams J G Miller <miller@yoyo.ORG> - 2013-03-17 20:04 +0000
Re: assigning specific /dev/videoN to specific USB webcams Kevin Snodgrass <kdsnodgrass@yahoo.com> - 2013-03-24 21:51 +0000
Re: assigning specific /dev/videoN to specific USB webcams J G Miller <miller@yoyo.ORG> - 2013-03-24 22:54 +0000
Re: assigning specific /dev/videoN to specific USB webcams Robert Heller <heller@deepsoft.com> - 2013-03-24 18:27 -0500
Re: assigning specific /dev/videoN to specific USB webcams J G Miller <miller@yoyo.ORG> - 2013-03-25 02:34 +0000
Re: assigning specific /dev/videoN to specific USB webcams Kevin Snodgrass <kdsnodgrass@yahoo.com> - 2013-03-31 18:16 +0000
Re: assigning specific /dev/videoN to specific USB webcams J G Miller <miller@yoyo.ORG> - 2013-03-31 19:33 +0000
Re: assigning specific /dev/videoN to specific USB webcams Kevin Snodgrass <kdsnodgrass@yahoo.com> - 2013-04-11 14:19 +0000
Re: assigning specific /dev/videoN to specific USB webcams J G Miller <miller@yoyo.ORG> - 2013-04-11 15:21 +0000
Re: assigning specific /dev/videoN to specific USB webcams Eric Pozharski <whynot@pozharski.name> - 2013-04-01 13:52 +0300
Re: assigning specific /dev/videoN to specific USB webcams J G Miller <miller@yoyo.ORG> - 2013-04-01 18:24 +0000
csiph-web