Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #7495 > unrolled thread

assigning specific /dev/videoN to specific USB webcams

Back to article view | Back to comp.os.linux.misc

Contents

  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

#7495 — assigning specific /dev/videoN to specific USB webcams

Is it possible to create a udev rule to assign specific
/dev/videoN numbers to USB  webcams. 

The driver is uvcvideo but video4linux is involved because udevadm reports

 KERNEL=="video0"
 SUBSYSTEM=="video4linux"
 DRIVER==""
 ATTR{name}=="Philips SPC 1300NC Webcam"
 ATTR{index}=="0"

and /var/log/udev

UDEV  [6.985589] add      /devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/vide
o4linux/video0 (video4linux)
ACTION=add
COLORD_DEVICE=1
COLORD_KIND=camera
DEVLINKS=/dev/v4l/by-id/usb-Philips_CE_Philips_SPC_1300NC_Webcam-video-index0 /d
ev/v4l/by-path/pci-0000:00:1d.7-usb-0:3:1.0-video-index0
DEVNAME=/dev/video0
DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/video4linux/video0
ID_BUS=usb
ID_MODEL=Philips_SPC_1300NC_Webcam
ID_MODEL_ENC=Philips\x20SPC\x201300NC\x20Webcam
ID_MODEL_ID=0331
ID_PATH=pci-0000:00:1d.7-usb-0:3:1.0
ID_PATH_TAG=pci-0000_00_1d_7-usb-0_3_1_0
ID_REVISION=0100
ID_SERIAL=Philips_CE_Philips_SPC_1300NC_Webcam
ID_TYPE=video
ID_USB_DRIVER=uvcvideo
ID_USB_INTERFACES=:0e0100:0e0200:010100:010200:
ID_USB_INTERFACE_NUM=00
ID_V4L_CAPABILITIES=:capture:
ID_V4L_PRODUCT=Philips SPC 1300NC Webcam
ID_V4L_VERSION=2
ID_VENDOR=Philips_CE
ID_VENDOR_ENC=Philips\x20CE
ID_VENDOR_ID=0471
MAJOR=81
MINOR=0
SEQNUM=2105
SUBSYSTEM=video4linux
TAGS=:udev-acl:
UDEV_LOG=3
USEC_INITIALIZED=6816309

I am trying to get this webcam on to /dev/video1 
and the other webcam a Logitech on to /dev/video0

I have tried various udev rules, one of which appeared to
give the desired results with udevadm test, but with an
actual reboot, nothing changed

The documentation for uvcvideo does not mention any possibility
of kernel parameters to specify the device numbering although
the v4l2 framework suggest that it *should*

QUOTE

  The last argument gives you a certain amount of control over the device
  device node number used (i.e. the X in videoX). Normally you will pass -1
  to let the v4l2 framework pick the first free number. But sometimes users
  want to select a specific node number. It is common that drivers allow
  the user to select a specific device node number through a driver module
  option. That number is then passed to this function and video_register_device
  will attempt to select that device node number.

UNQUOTE

[toc] | [next] | [standalone]

#7497

At Sun, 17 Mar 2013 19:20:55 +0000 (UTC) J G Miller <miller@yoyo.ORG> wrote:

> 
> 
> Is it possible to create a udev rule to assign specific
> /dev/videoN numbers to USB  webcams. 
> 
> The driver is uvcvideo but video4linux is involved because udevadm reports
> 
>  KERNEL=="video0"
>  SUBSYSTEM=="video4linux"
>  DRIVER==""
>  ATTR{name}=="Philips SPC 1300NC Webcam"
>  ATTR{index}=="0"
> 
> and /var/log/udev
> 
> UDEV  [6.985589] add      /devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/vide
> o4linux/video0 (video4linux)
> ACTION=add
> COLORD_DEVICE=1
> COLORD_KIND=camera
> DEVLINKS=/dev/v4l/by-id/usb-Philips_CE_Philips_SPC_1300NC_Webcam-video-index0 /d
> ev/v4l/by-path/pci-0000:00:1d.7-usb-0:3:1.0-video-index0
> DEVNAME=/dev/video0
> DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/video4linux/video0
> ID_BUS=usb
> ID_MODEL=Philips_SPC_1300NC_Webcam
> ID_MODEL_ENC=Philips\x20SPC\x201300NC\x20Webcam
> ID_MODEL_ID=0331
> ID_PATH=pci-0000:00:1d.7-usb-0:3:1.0
> ID_PATH_TAG=pci-0000_00_1d_7-usb-0_3_1_0
> ID_REVISION=0100
> ID_SERIAL=Philips_CE_Philips_SPC_1300NC_Webcam
> ID_TYPE=video
> ID_USB_DRIVER=uvcvideo
> ID_USB_INTERFACES=:0e0100:0e0200:010100:010200:
> ID_USB_INTERFACE_NUM=00
> ID_V4L_CAPABILITIES=:capture:
> ID_V4L_PRODUCT=Philips SPC 1300NC Webcam
> ID_V4L_VERSION=2
> ID_VENDOR=Philips_CE
> ID_VENDOR_ENC=Philips\x20CE
> ID_VENDOR_ID=0471
> MAJOR=81
> MINOR=0
> SEQNUM=2105
> SUBSYSTEM=video4linux
> TAGS=:udev-acl:
> UDEV_LOG=3
> USEC_INITIALIZED=6816309
> 
> I am trying to get this webcam on to /dev/video1 
> and the other webcam a Logitech on to /dev/video0
> 
> I have tried various udev rules, one of which appeared to
> give the desired results with udevadm test, but with an
> actual reboot, nothing changed

It is nearly impossible to map specific USB devices to specific device
files using any sort of generic information, esp if the devices are the
same make and model. Do these devices have *unique* serial numbers?  If
so, then you can key off the serial number.

> 
> The documentation for uvcvideo does not mention any possibility
> of kernel parameters to specify the device numbering although
> the v4l2 framework suggest that it *should*
> 
> QUOTE
> 
>   The last argument gives you a certain amount of control over the device
>   device node number used (i.e. the X in videoX). Normally you will pass -1
>   to let the v4l2 framework pick the first free number. But sometimes users
>   want to select a specific node number. It is common that drivers allow
>   the user to select a specific device node number through a driver module
>   option. That number is then passed to this function and video_register_device
>   will attempt to select that device node number.
> 
> UNQUOTE
>        

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                                  

[toc] | [prev] | [next] | [standalone]

#7498

On Sunday, March 17th, 2013, at 14:46:58h -0500, Robert Heller explained:

> It is nearly impossible to map specific USB devices to specific device
> files using any sort of generic information, esp if the devices are the
> same make and model. Do these devices have *unique* serial numbers?  If
> so, then you can key off the serial number.


looking at device '/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/video4linux/video0':
    KERNEL=="video0"
    SUBSYSTEM=="video4linux"
    DRIVER==""
    ATTR{name}=="Philips SPC 1300NC Webcam"


hence an attempt with

SUBSYSTEM=="video4linux",	ATTR{name}="HD Pro Webcam C920",	\
				NAME="video0"
#
SUBSYSTEM=="video4linux",	ATTR{name}="Philips SPC 1300NC Webcam",	\
				NAME="video1"

but that make no difference after a reboot (just tried) --
Philips is still on video0 and Logitech on video1

Or maybe you can see the fatal error/stupidity in the above rules?


looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0':
    KERNELS=="2-3:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="uvcvideo"

    <nothing obvious>

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb2/2-3':
    KERNELS=="2-3"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ...
    
    ATTRS{product}=="Philips SPC 1300NC Webcam"
    ATTRS{idProduct}=="0331"
    ATTRS{idVendor}=="0471"



I tried a rule with the idProduct and idVendor at the USB level
to set NAME but that did not work because I suspect it was
overruled further down the chain at the uvcvideo or video4linux level

    

[toc] | [prev] | [next] | [standalone]

#7639

On Sun, 17 Mar 2013 19:20:55 +0000, J G Miller wrote:

> Is it possible to create a udev rule to assign specific /dev/videoN
> numbers to USB  webcams.

I've been trying to deal with this myself ever since udev showed up.

I have 2 DVRs, 1 has 2 identical Hauppauge PVR-250 cards, but they are 
just straight NTSC cable, so it doesn't matter which is assigned /dev/
video0 at boot.  But the other machine has 1 PVR-250 attached to my cable 
box, 1 pcHDTV 3000 and a webcam.  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, which means I have to manually check by 
running mplayer /dev/video1 to see if it is the PVR-250.

What really sucks is if I'm gone and lose power, when it reboots it may 
come up with the 2 cards switched and a timed record will of course be 
screwed up.

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 ?  It does make "roll-
your-own" DVRs harder to write. (I hate MythTV)

[toc] | [prev] | [next] | [standalone]

#7642

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?

> 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.

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.

> 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 ?

Well the explanation for that is not too difficult, but I can only give
it in general terms.  Your analog cards are assigned /dev/videoN device
ids (as is the case for webcams) by the appropriate video4linux v4l2 kernel
module whereas for DVB devices, the appropriate video4linux DVB modules
create a directory adapter under which there are device files for each of
the capabilities of the card, eg for a Terratec Cinergy 1200 DVB-t

ll /dev/dvb/adapter0/
total 0
0 drwxr-xr-x 2 root root     140 2013-03-24 21:03 ./
0 drwxr-xr-x 3 root root      60 2013-03-24 21:03 ../
0 crw-rw---- 1 root video 212, 4 2013-03-24 21:03 ca0
0 crw-rw---- 1 root video 212, 0 2013-03-24 21:03 demux0
0 crw-rw---- 1 root video 212, 1 2013-03-24 21:03 dvr0
0 crw-rw---- 1 root video 212, 3 2013-03-24 21:03 frontend0
0 crw-rw---- 1 root video 212, 2 2013-03-24 21:03 net0

So oversimplifying perhaps -- analog video devices
use /dev/videoN files, whereas digital video devices use
/dev/dvb/adapterN directories.


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?

[toc] | [prev] | [next] | [standalone]

#7648

At Sun, 24 Mar 2013 22:54:57 +0000 (UTC) J G Miller <miller@yoyo.ORG> 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?
> 
> > 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.
> 
> 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.

The scan of the PCI bus *ought* to be deterministic, based on slot
numbers: from low to high or high to low.

Do these devices have some sort of unique id (like a serial number)?

> 
> > 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 ?
> 
> Well the explanation for that is not too difficult, but I can only give
> it in general terms.  Your analog cards are assigned /dev/videoN device
> ids (as is the case for webcams) by the appropriate video4linux v4l2 kernel
> module whereas for DVB devices, the appropriate video4linux DVB modules
> create a directory adapter under which there are device files for each of
> the capabilities of the card, eg for a Terratec Cinergy 1200 DVB-t
> 
> ll /dev/dvb/adapter0/
> total 0
> 0 drwxr-xr-x 2 root root     140 2013-03-24 21:03 ./
> 0 drwxr-xr-x 3 root root      60 2013-03-24 21:03 ../
> 0 crw-rw---- 1 root video 212, 4 2013-03-24 21:03 ca0
> 0 crw-rw---- 1 root video 212, 0 2013-03-24 21:03 demux0
> 0 crw-rw---- 1 root video 212, 1 2013-03-24 21:03 dvr0
> 0 crw-rw---- 1 root video 212, 3 2013-03-24 21:03 frontend0
> 0 crw-rw---- 1 root video 212, 2 2013-03-24 21:03 net0
> 
> So oversimplifying perhaps -- analog video devices
> use /dev/videoN files, whereas digital video devices use
> /dev/dvb/adapterN directories.
> 
> 
> 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?
>                                                                           

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                                                        

[toc] | [prev] | [next] | [standalone]

#7651

On Sunday, March 24th, 2013, at 18:27:18h -0500, Robert Heller advised:

> The scan of the PCI bus *ought* to be deterministic, based on slot
> numbers: from low to high or high to low.

Indeed so, as confirmed by the order of things in /var/log/udev

> Do these devices have some sort of unique id (like a serial number)?

If you look in /var/log/udev you will see things such as, on one machine

      /devices/pci0000:00/0000:00:0b.0

is where the SATA pci card is located

     /devices/pci0000:00/0000:00:0c.0

is where the DVB-t pci card is located, so as I suggested previously,
it could be possible if there were two cards of the same type at
00:0b and 00:0c to be differentied by this device to pci slot
identifier.

[toc] | [prev] | [next] | [standalone]

#7709

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.)

[toc] | [prev] | [next] | [standalone]

#7710

On Sunday, March 31st, 2013, at 18:16:36h +0000, Kevin Snodgrass wrote:

> ok, but WHY does V4L assign analog devices /dev/videoX and digital /dev/
> dvb/adapterX ?

As I tried to explain/second guess, back in the days of the analog devices,
the developers only recognized one "capability/feature" on the card and
so that was /dev/videoN.

For digital cards, these have more than one "capability/feature"
and so require a directory to keep the device interface files
together.

It is similar to the way there was a change for audio in device interface
files in going from OSS to ALSA.

Under OSS, an audio card has /dev/dspN and /dev/mixerN and maybe
/dev/sequencerN.  Now under ALSA, everything is kept
together under /dev/snd.

They should have used a similar scheme to v4l2 of /dev/snd/card0,
/dev/snd/card1 as for DVB cards, but as you so correctly observed
there is a more or less a total lack of consist*e*ncy between
different kernel modules, and I suppose, ultimately the blame
for that can be laid at the foot of Linus Torvalds, who will probably
respond that he could care less about such issues.

There seems to be a general attitude of "so long as it works"
(sort of anyways), that is good enough, so stop asking awkward
questions.

Maybe they do things more logically and consistently in BSD
with their benevolent dictatorship style of management, rather
than the Linux laissez-faire approach?

Anyways I am still awaiting (probably in vain) for some
help with udev rules, since obviously this is the wrong group
in which to post such a technical question.

[toc] | [prev] | [next] | [standalone]

#7840

On Sun, 31 Mar 2013 19:33:32 +0000, J G Miller wrote:

> On Sunday, March 31st, 2013, at 18:16:36h +0000, Kevin Snodgrass wrote:
> 
>> ok, but WHY does V4L assign analog devices /dev/videoX and digital
>> /dev/ dvb/adapterX ?
> 
> As I tried to explain/second guess, back in the days of the analog
> devices, the developers only recognized one "capability/feature" on the
> card and so that was /dev/videoN.
> 
> For digital cards, these have more than one "capability/feature" and so
> require a directory to keep the device interface files together.

[snippage]

Ok, all fine and dandy.  But V4L does CREATE /dev/videoN for the card, 
but it is USELESS, ie if you want to do "mplayer /dev/videoN" it doesn't 
work.  So why have that device node if it has no use?

BTW, V4L makes 3 device nodes for each PVR-250 card.

$ ls -l /dev/video*
crw-rw----+ 1 root video 81, 0 Apr 11 08:45 /dev/video0
crw-rw----+ 1 root video 81, 1 Apr 11 08:45 /dev/video1
crw-rw----+ 1 root video 81, 4 Apr 11 08:45 /dev/video2
crw-rw----+ 1 root video 81, 7 Apr 11 08:45 /dev/video26
crw-rw----+ 1 root video 81, 5 Apr 11 08:45 /dev/video34
$ 

In this case, /dev/video0 is a USB webcam, /dev/video1 is a pcHDTV 3000, 
and /dev/video2, /dev/video26 and /dev/video34 are all created for a 
PVR-250, but the /dev/video2 is the actual video device.  And one point 
some years ago I actually knew what the other 2 device nodes were, but 
can't remember now.

On my other DVR I get this:

$ ls -l /dev/video*
crw-rw----+ 1 root video 81, 0 Apr  8 09:24 /dev/video0
crw-rw----+ 1 root video 81, 4 Apr  8 09:24 /dev/video1
crw-rw----+ 1 root video 81, 3 Apr  8 09:24 /dev/video24
crw-rw----+ 1 root video 81, 7 Apr  8 09:24 /dev/video25
crw-rw----+ 1 root video 81, 1 Apr  8 09:24 /dev/video32
crw-rw----+ 1 root video 81, 5 Apr  8 09:24 /dev/video33
$ 

That computer has 2 identical PVR-250 cards.


Anyway, that is all minor compared to the semi-random nature of assigning 
device node names to hardware of similar/same category.

[toc] | [prev] | [next] | [standalone]

#7842

On Thursday, April 11th, 2013, at 14:19:26h +0000,
Kevin Snodgrass exclaimed:

> But V4L does CREATE /dev/videoN for the card, but it is USELESS

It is *not* USELESS, it is essential for certain things to work.

> ie if you want to do "mplayer /dev/videoN" it doesn't work.

Of course it does not -- things are useless if you do not know how
to use them -- and in the case of mplayer you are not telling
mplayer how to use /dev/videoN.

From <http://www.linuxquestions.ORG/questions/linux-general-1/mplayer-tv-device%3D-dev-video0-tv-dumpfile-file2300-avi-not-working-824791/>

QUOTE

   mplayer -tv device=/dev/video0 tv:// 

   works flawlessly well.

UNQUOTE

A quick web search reveals that this correct parameter speficication
works well for other people as well, including other settings as well,
eg

from <http://mplayerhq.hu/pipermail/mplayer-users/2005-April/052844.html>

QUOTE

   the mplayer -tv  
   options worked just fine for me. This is the line I used:

mplayer -tv  
device=/dev/video:driver=v4l:input=1:width=320:height=240:norm=ntsc: 
adevice=/dev/dsp tv://1 -zoom -aspect 4:3

UNQUOTE

Also take a look at

  <http://brightedges.blogspot.COM/2008/06/webcam-and-mplayer.html>

and the "gold standard" reference at

  <http://www.linuxtv.ORG/wiki/index.php/MPlayer>

Remember mplayer is very fussy about its command line parameters
and it takes years to learn how to use them all.

I still struggle just getting dvd:// to work  ;)

[toc] | [prev] | [next] | [standalone]

#7713

with <ki552n$nat$1@dont-email.me> J G Miller wrote:
>
> Is it possible to create a udev rule to assign specific
> /dev/videoN numbers to USB  webcams. 

If my reading of devices.txt is correct then /dev/videoN is real
character special and supplied by kernel itself.  Then, I believe,
answer is -- no.  Quoting udev(7):

	Also, as a temporary workaround, this is what a device node
	should be named; usually the kernel provides the defined node
	name or creates and removes the node before udev even receives
	any event.  Changing the node name from the kernel's default
	creates inconsistencies and is not supported. If the kernel and
	NAME specify different names, an error is logged. udev is only
	expected to handle device node permissions and to create
	additional symlinks, not to change kernel-provided device node
	names. Instead of renaming a device node, SYMLINK should be
	used. However, symlink names must never conflict with device
	node names, as that would result in unpredictable behavior.

Shortly, it's possible to create device specials but kernel won't give a
fsck.  I suggest that symlinks are fine too.

*SKIP*
> I have tried various udev rules, one of which appeared to
> give the desired results with udevadm test, but with an
> actual reboot, nothing changed

Probably, udev rules written in initrd fail to play accordingly.  Or
fail to play at all (and logs are written to syslog what's is missing so
far).

*CUT*

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[toc] | [prev] | [next] | [standalone]

#7714

On Monday, April 1st, 2013, at 13:52:12 +0300, Eric Pozharski wrote:

> with <ki552n$nat$1@dont-email.me> J G Miller wrote:
>>
>> Is it possible to create a udev rule to assign specific
>> /dev/videoN numbers to USB  webcams. 
> 
> If my reading of devices.txt is correct then /dev/videoN is real
> character special and supplied by kernel itself.  Then, I believe,
> answer is -- no. 

Thank you for the response and thank you also for the explanation!

Looks like being forced to use symlinks to /dev/webcam1, /dev/webcam2
etc and change configurations of applications to point to these rather
than /dev/videoN.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web