Re: Udev. Problems with ordering hardware using /dev/video
On Wednesday 01 August 2007 19:21, Florian Kulzer wrote:
> On Wed, Aug 01, 2007 at 00:45:54 +0200, Nigel Henry wrote:
> > > On Tue, Jul 31, 2007 at 19:47:51 +0200, Nigel Henry wrote:
>
> [...]
>
> > > > My TV card was set as /dev/video0, and some time later the webcam was
> > > > set as /dev/video1. this works fine with the pre 2.6.17 kernels (no
> > > > Udev), and the TV card consistently is /dev/video0, and the webcam
> > > > /dev/video1. Booting with the 2.6.17 kernel is a different scenario.
> > > > Very hit and miss. Sometimes I boot up and starting Xawtv, I get the
> > > > TV /dev/video0. Othertimes I bootup and start Xawtv, and get my
> > > > webcam /dev/video1.
>
> [...]
>
> > Output below. Bear in mind that /dev/video0 should be the TV card,
> > /dev/video1 the webcam, at least that is how they are loaded with pre
> > Udev kernels.
>
> [...]
>
> > djmons@debian:~$ udevinfo -a -p $(udevinfo -q path -n /dev/video0)
>
> [...]
>
> > looking at device '/class/video4linux/video0':
> > KERNEL=="video0"
> > SUBSYSTEM=="video4linux"
> > DRIVER==""
> > ATTR{exposure}=="0"
> > ATTR{hue}=="128"
> > ATTR{contrast}=="54"
> > ATTR{saturation}=="110"
> > ATTR{brightness}=="124"
> > ATTR{sensor}=="OV7620"
> > ATTR{bridge}=="OV511+"
> > ATTR{model}=="Generic Camera _no ID_"
> > ATTR{custom_id}=="0"
> > ATTR{name}=="OV511 USB Camera"
> > ATTR{dev}=="81:0"
>
> [...]
>
> > djmons@debian:~$ udevinfo -a -p $(udevinfo -q path -n /dev/video1)
>
> [...]
>
> > looking at device '/class/video4linux/video1':
> > KERNEL=="video1"
> > SUBSYSTEM=="video4linux"
> > DRIVER==""
> > ATTR{card}=="10"
> > ATTR{name}=="BT878 video _Hauppauge _bt878__"
> > ATTR{dev}=="81:1"
>
> [...]
>
> > I saw that someone with network device problems, and Udev, was able to
> > specify the devices by name on 2 separate lines, so that Udev always
> > recognised them by name. I don't know if something similar is possible
> > with my situation with the TV card, and the webcam.
>
> For network cards see: /etc/udev/rules.d/z25_persistent-net.rules.
>
> /usr/share/doc/udev/writing_udev_rules/index.html describes in detail
> how udev rules work. Based on the output that you posted this should
> get you started:
>
> ### START ###
>
> SUBSYSTEM=="video4linux", \
> ATTR{name}=="BT878 video _Hauppauge _bt878__", \
> NAME="video0"
>
> SUBSYSTEM=="video4linux", \
> ATTR{name}=="OV511 USB Camera", \
> NAME="video1"
>
> ### END ###
>
> Put these rules into a file "local-tvwebcam.rules" in /etc/udev/ with
> ownership and permissions like the other *.rules files in this
> directory. Then create a symlink ("ln -s ...") in /etc/udev/rules.d/
> which points to your rules file. The names in rules.d determine the
> order in which the rules are tested. You might have to experiment a bit;
> I would try to start with something like 010_... .
Hi Florian. What you've suggested above seems to be working ok. I rebooted a
couple of times with the 2.6.17 kernel and Lenny, and the video devices are
being loaded in the correct order. So far so good. I think I'll have to boot
up Lenny a few more times to see if this is now consistent regarding the
video devices.
>
> My experience with network cards was that the NAME assignments sometimes
> did not work reliably if I tried to use them to swap two existing
> (kernel) names (i.e. eth0 and eth1). If you have similar problems then
> it is probably best to replace the two NAME assignments in the rules by
> two SYMLINK directives:
>
> ### START ###
>
> SUBSYSTEM=="video4linux", \
> ATTR{name}=="BT878 video _Hauppauge _bt878__", \
> SYMLINK+="mytvcard"
>
> SUBSYSTEM=="video4linux", \
> ATTR{name}=="OV511 USB Camera", \
> SYMLINK+="mywebcam"
>
> ### END ###
>
> This will give you /dev/mytvcard and /dev/mywebcam as symlinks which
> should always point to the correct /dev/video? device. Then you just
> have to reconfigure your applications once to use the device symlinks
> instead of the video? nodes.
>
> --
> Regards, | http://users.icfo.es/Florian.Kulzer
> Florian |
Thanks a bunch for your help. Perhaps the problem is now resolved. (Don't
speak too soon though)
Nigel.
Reply to: