[mythtv-users] Cards keep changing /dev/videoX devices...

Alan Calvert cal at graggrag.com
Fri Jun 15 04:45:47 UTC 2007


R. G. Newbury wrote:
> Steve Smith wrote:
>> Alan,
>>
>> Great! Nice and simple...
>>
>> I do like the idea of a udev "freeze/dump current config" type feature,
>> that'd be really useful for the generic case...
>>
>> Cheers
>>
>> Steve
>>
>> On 14/06/07, Alan Calvert <cal at graggrag.com> wrote:
>>> Steve Smith wrote:
>>>> I have two cards in my system; a PVR-150 and a WinFast DTV-1000T.
>>>>
>>>> The devices work "OK", but every reboot get assigned /dev/video0 and
>>>> /dev/video1 in a random order so the myth config keeps getting
>>>> messed up.
>>>>
>>>> Is there anyway to stabilise them?
>>> Messing with udev rules to control this is unnecessary, and overly
>>> complicated. Most of the driver modules take a parameter to specify
>>> what device it should use when modprobed. With ivtv, it's
>>> 'ivtv_first_minor',
>>> and with cx8800 (the DTV-1000) it's  video_nr and radio_nr. Try
>>> 'modinfo ivtv' and 'modinfo cx8800' (as root) for the full list of
>>> options .
>>>
>>> I have the same mix of cards in my system, two DTV-1000's actually,
>>> and in a file /etc/modprobe.d/mythtv I have ...
>>>     options cx8800 video_nr=0,1 radio_nr=0,1 vbi_nr=0,1
>>>     options ivtv pal=BG ivtv_first_minor=2
>>> So the two DTV1000s are always /dev/video0, /dev/video1, and the
>>> PVR-150 always comes up as /dev/video2 (and friends).
>>>
>>> Simple as that. Cheers!
> 
> You should also understand that the cx88 driver is built into the 
> kernel, and will be called/installed before the ivtv driver is 
> called/installed. And the 'wrong' cx88 driver might be the one the 
> kernel installs, as it hasn't yet looked at modprobe.conf.

No offence, but that's nonsense. It would be _most_ unusual for the
cx88 driver to be built into the kernel. More likely, the kernel is
autoloading the module having discovered the video card and identified
the appropriate driver module for it.
   
> This causes problems where an HD3000 is being used for digital. You 
> wouldn't want the cx8800 driver (and /dev/video0 being stolen). You 
> would want the cx88_dvb driver being loaded instead. The answer is to 
> blacklist the driver you do NOT want (or ALL of them), and remove 
> drivers, if necessary, from modprobe.conf, and load your drivers in 
> order, in rc.local.
> 
> So, for my setup, I blacklisted cx8800 and cx88_dvb, and then loaded 
> cx88_dvb by a line in rc.local. The PVR500 then gets /dev/video1 and 
> video2, through the ivtv driver, and there will be nothing in the way, 
> and that is the first driver call to latch onto that spot.
> 
> In your case, the cx8800 driver is likely being loaded by the kernel as 
> soon as the hardware is recognized. But your modprobe.conf is likely set 
> up on the assumption that the ivtv driver will be called first (you 
> listed it first, and computers *ALWAYS* do exactly what we want, and in 
> the order we want...right? Right?).

Again, half-baked nonsense. If your video device allocations are explicitly
set in modprobe.conf (or other related module config files) then regardless
of how or when the video driver module gets loaded - kernel autoload,
/etc/modules, rc.local, whererever/whenever - the assignment of video device
numbers will _always_ be as specified by your options settings. 
  
> You might want to try commenting out everything in modprobe.conf and see 
> what ends loaded. Then try 'modprobe -r cx8800' in rc.local and see if 
> anything at all is loaded. Then try the ivtv lines in modprobe.conf. And 
> finally, try a 'modprobe cx8800' in rc.local.
> 
> I would bet (a small wager!) that the last is a stable result.

Yep, blacklisting everything and ordering the module loads explicitly in
rc.local works, as does using a sledgehammer to crack a nut. Simply allocating
video device numbers explicitly by means of module options also works.

No desire for argument here, but some of the advice presented was simply false
and misleading.

cheers.  


More information about the mythtv-users mailing list