Udev. Problems with ordering hardware using /dev/video

On Tuesday 31 July 2007 23:21, Florian Kulzer wrote:
> On Tue, Jul 31, 2007 at 19:47:51 +0200, Nigel Henry wrote:
> > I've managed to resolve most of my problems on my own, but Udev has
> > beaten me.
> >
> > Sarge is not a problem, as it's using the 2.4.27, or 2.6.8 kernel, and
> > Udev is not in the equation. Etch has a 2.6.8, and a 2.6.17 kernel, and
> > Lenny has a 2.6.11, and a 2.6.17 kernel. The problem is with the 2.6.17
> > kernel that uses Udev.
> >
> > 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.
>
> This flip-flopping is, AFAIK, more the fault of the newer kernel then
> the fault of udev. If the kernel would always load the modules in the
> same order then udev would probably assign the device nodes in a
> consistent manner.
>
> > I've worked with ordering my soundcards, and the lines are quite simple,
> > and have seen that something similar is possible with Udev, although the
> > lines a re a bit more complex. Could someone give me a couple of lines so
> > that my TV card is always /dev/video0, and the webcam is always
> > /dev/video1?
> >
> > Any help gratefully appreciated for fixing this annoying problem.
>
> Post the output of:
>
> udevinfo -a -p $(udevinfo -q path -n /dev/video0)
>
> udevinfo -a -p $(udevinfo -q path -n /dev/video1)
>
> (Only the blocks that have things like "ATTRS{model}" or "ATTRS{vendor}"
> are important.)
>
> --
> Regards, | http://users.icfo.es/Florian.Kulzer
> Florian |

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.

ssh 192.168.0.8
Password:
Linux debian 2.6.17-2-686 #1 SMP Wed Sep 13 16:34:10 UTC 2006 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Jul 31 20:37:05 2007
djmons@debian:~$ udevinfo -a -p $(udevinfo -q path -n /dev/video0)

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

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"

looking at parent device '/devices/pci0000:00/0000:00:07.2/usb1/1-2':
KERNELS=="1-2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{maxchild}=="0"
ATTRS{version}==" 1.00"
ATTRS{devnum}=="3"
ATTRS{speed}=="12"
ATTRS{bMaxPacketSize0}=="8"
ATTRS{bNumConfigurations}=="1"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceClass}=="00"
ATTRS{bcdDevice}=="0100"
ATTRS{idProduct}=="a511"
ATTRS{idVendor}=="05a9"
ATTRS{bMaxPower}=="500mA"
ATTRS{bmAttributes}=="80"
ATTRS{bConfigurationValue}=="1"
ATTRS{bNumInterfaces}==" 1"

looking at parent device '/devices/pci0000:00/0000:00:07.2/usb1':
KERNELS=="usb1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{serial}=="0000:00:07.2"
ATTRS{product}=="UHCI Host Controller"
ATTRS{manufacturer}=="Linux 2.6.17-2-686 uhci_hcd"
ATTRS{maxchild}=="2"
ATTRS{version}==" 1.10"
ATTRS{devnum}=="1"
ATTRS{speed}=="12"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{bNumConfigurations}=="1"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceClass}=="09"
ATTRS{bcdDevice}=="0206"
ATTRS{idProduct}=="0000"
ATTRS{idVendor}=="0000"
ATTRS{bMaxPower}==" 0mA"
ATTRS{bmAttributes}=="e0"
ATTRS{bConfigurationValue}=="1"
ATTRS{bNumInterfaces}==" 1"

looking at parent device '/devices/pci0000:00/0000:00:07.2':
KERNELS=="0000:00:07.2"
SUBSYSTEMS=="pci"
DRIVERS=="uhci_hcd"
ATTRS{modalias}=="pci:v00001106d00003038sv00000925sd00001234bc0Csc03i00"
ATTRS{local_cpus}=="ff"
ATTRS{irq}=="11"
ATTRS{class}=="0x0c0300"
ATTRS{subsystem_device}=="0x1234"
ATTRS{subsystem_vendor}=="0x0925"
ATTRS{device}=="0x3038"
ATTRS{vendor}=="0x1106"

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

djmons@debian:~$ udevinfo -a -p $(udevinfo -q path -n /dev/video1)

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/class/video4linux/video1':
KERNEL=="video1"
SUBSYSTEM=="video4linux"
DRIVER==""
ATTR{card}=="10"
ATTR{name}=="BT878 video _Hauppauge _bt878__"
ATTR{dev}=="81:1"

looking at parent device '/devices/pci0000:00/0000:00:0a.0':
KERNELS=="0000:00:0a.0"
SUBSYSTEMS=="pci"
DRIVERS=="bttv"
ATTRS{modalias}=="pci:v0000109Ed0000036Esv00000070sd000013EBbc04sc00i00"
ATTRS{local_cpus}=="ff"
ATTRS{irq}=="10"
ATTRS{class}=="0x040000"
ATTRS{subsystem_device}=="0x13eb"
ATTRS{subsystem_vendor}=="0x0070"
ATTRS{device}=="0x036e"
ATTRS{vendor}=="0x109e"

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

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.

Thanks for your concern.

Nigel.

--

On Tue, Jul 31, 2007 at 11:21:27PM +0200, Florian Kulzer wrote:

> This flip-flopping is, AFAIK, more the fault of the newer kernel then
> the fault of udev. If the kernel would always load the modules in the
> same order then udev would probably assign the device nodes in a
> consistent manner.

I disagree. Udev is responsible for creating device nodes. It should
remember what devices nodes it has made in the past for different
devices, and recreate them the same way in the futuer. Yes, this could
mean that if a webcam is video0 and a TV card is video1 that if the
webcam is not connected there will be no video0, but that would be fine.
Over the life of a box, I could see that there may be videos starting
with video20. The only problem with this is that we enumerate drives with
letters instead of numbers.

This whole udev mess, and devfs before it, was to address the rampant
growth in device nodes/names. It seems to have brought with it a whole
slew of its own problems.

Doug.

--