Having a look at the udev info
here, here, and
here gave me pointers, but the
ivtv Wiki gives an example.
Working through the steps,
Code:
bruce@homenet-pvr:~$ udevinfo -e |less
P: /class/video4linux/radio0
N: radio0
P: /class/video4linux/vbi0
N: vbi0
P: /class/video4linux/vbi1
N: vbi1
P: /class/video4linux/vbi16
N: vbi16
P: /class/video4linux/vbi2
N: vbi2
P: /class/video4linux/vbi8
N: vbi8
P: /class/video4linux/video0
N: video0
P: /class/video4linux/video1
N: video1
P: /class/video4linux/video16
N: video16
P: /class/video4linux/video2
N: video2
P: /class/video4linux/video24
N: video24
P: /class/video4linux/video32
N: video32
P: /class/video4linux/video48
N: video48
I extracted the relevant info, the above has been edited to remove all the other devices.
So at this boot, it was still video0, so I needed to get more info about it:
Code:
bruce@homenet-pvr:~$ udevinfo -a -p /class/video4linux/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{name}=="ivtv0 encoder MPEG"
ATTR{dev}=="81:0"
looking at parent device '/devices/pci0000:00/0000:00:09.0/0000:05:06.0':
KERNELS=="0000:05:06.0"
SUBSYSTEMS=="pci"
DRIVERS=="ivtv"
ATTRS{broken_parity_status}=="0"
ATTRS{modalias}=="pci:v00004444d00000803sv00000070sd00004000bc04sc00i00"
ATTRS{local_cpus}=="ffffffff"
ATTRS{irq}=="20"
ATTRS{class}=="0x040000"
ATTRS{subsystem_device}=="0x4000"
ATTRS{subsystem_vendor}=="0x0070"
ATTRS{device}=="0x0803"
ATTRS{vendor}=="0x4444"
looking at parent device '/devices/pci0000:00/0000:00:09.0':
KERNELS=="0000:00:09.0"
SUBSYSTEMS=="pci"
DRIVERS==""
ATTRS{broken_parity_status}=="0"
ATTRS{modalias}=="pci:v000010DEd0000005Csv00000000sd00000000bc06sc04i01"
ATTRS{local_cpus}=="ffffffff"
ATTRS{irq}=="0"
ATTRS{class}=="0x060401"
ATTRS{subsystem_device}=="0x0000"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{device}=="0x005c"
ATTRS{vendor}=="0x10de"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
So using the info above and from the links, I created a local.rules file in /etc/udev and tried to get a symlink to whatever /dev/videoX device would be used, as follows:
Code:
root@homenet-pvr:/home/bruce#cd /etc/udev
root@homenet-pvr:/etc/udev#nano local.rules
DRIVERS=="ivtv", SYSFS{name}=="ivtv? encoder MPEG", ID=="0000:05:06.0", NAME="video", SYMLINK+="pvr_350", GROUP="video"
root@homenet-pvr:/etc/udev# cd rules.d
root@homenet-pvr:/etc/udev/rules.d#ln -s ../local.rules z99_local.rules
So after the reboot the symlink worked and would follow whatever device the PVR350 would be at. Unfortunately I still was not able to select the symlink in mythtv-setup and it would not change the symlink group to video. So modifying the local.rules file to:
Code:
DRIVERS=="ivtv", SYSFS{name}=="ivtv? encoder MPEG", ID=="0000:05:06.0", NAME="video", SYMLINK+="pvr_350", GROUP="video"
This forces the PVR350 to /dev/video, resulting in the following:
Code:
bruce@homenet-pvr:~$ ls -l /dev/pv*
lrwxrwxrwx 1 root root 5 Jan 16 19:53 /dev/pvr_350 -> video
bruce@homenet-pvr:~$ ls -l /dev/video*
crw-rw---- 1 root video 81, 1 Jan 16 19:53 /dev/video
crw-rw---- 1 root video 81, 0 Jan 16 19:53 /dev/video0
crw-rw---- 1 root video 81, 16 Jan 16 19:53 /dev/video16
crw-rw---- 1 root video 81, 2 Jan 16 19:53 /dev/video2
crw-rw---- 1 root video 81, 24 Jan 16 19:53 /dev/video24
crw-rw---- 1 root video 81, 32 Jan 16 19:53 /dev/video32
crw-rw---- 1 root video 81, 48 Jan 16 19:53 /dev/video48
Going into mythtv-setup, allowed me to set the device to /dev/video, though in tuner setup, it still showed /dev/video1. Restarting the backend, then the frontend, generated "Can't connect to backend" error, so stopping the backend and going into mythtv-setup, I deleted the tuner and recreated it, using /dev/video.
Restarting the backend and frontend, everything seems to be OK, though doing the following:
Code:
root@homenet-pvr:/etc/udev# dmesg |grep ivtv
ivtv: ==================== START INIT IVTV ====================
ivtv: version 0.8.2 (tagged release) loading
ivtv: Linux version: 2.6.18-chw-13 SMP preempt mod_unload 586 gcc-4.1
ivtv: In case of problems please include the debug info between
ivtv: the START INIT IVTV and END INIT IVTV lines, along with
ivtv: any module options, when mailing the ivtv-users mailinglist.
ivtv0: Autodetected Hauppauge card (cx23415 based)
ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
ivtv0: loaded v4l-cx2341x-dec.fw firmware (262144 bytes)
tuner 3-0043: chip found @ 0x86 (ivtv i2c driver #0)
tuner 3-0061: chip found @ 0xc2 (ivtv i2c driver #0)
msp3400 3-0040: MSP4418G-B3 found @ 0x80 (ivtv i2c driver #0)
saa7115 3-0021: saa7115 found @ 0x42 (ivtv i2c driver #0)
ivtv0: Autodetected Hauppauge WinTV PVR-350
saa7127 3-0044: saa7129 found @ 0x88 (ivtv i2c driver #0)
ivtv0: Encoder revision: 0x02050032
ivtv0: Decoder revision: 0x02020023
ivtv0: Registered device video1 for encoder MPEG
ivtv0: Registered device video32 for encoder YUV
ivtv0: Registered device vbi1 for encoder VBI
ivtv0: Registered device video24 for encoder PCM audio
ivtv0: Registered device radio0 for encoder radio
ivtv0: Registered device video16 for decoder MPEG
ivtv0: Registered device vbi8 for decoder VBI
ivtv0: Registered device vbi16 for decoder VOUT
ivtv0: Registered device video48 for decoder YUV
ivtv0: loaded v4l-cx2341x-init.mpg firmware (155648 bytes)
ivtv0: Initialized Hauppauge WinTV PVR-350, card #0
ivtv: ==================== END INIT IVTV ====================
Shows that /dev/video1 is still being created for ivtv, it must then be changed by udev to /dev/video. I don't know what this does to the drivers, it's possible that the local.rules symlink needs to changed to a smaller number so it's triggered earlier in the udev sequence. It does seem to work, though I haven't rebooted yet as the box has been fairly busy.
Hope this helps someone else as well.
Bruce S.