[pvrusb2] Seperate Devices ..

[Mike Isely]

On Wed, 21 Jan 2009, Mike Ingardia wrote:

> So in a few instances I have read/ or in your most recent reply that I have
> to use a different device.  The only device I know that the driver creates
> is the one under /dev/video0.  Is there a different one?  or is it that I
> create two "logical devices" that both point to the /dev/video0 but are
> configured differently i.e. one is analog the other is digital.

The path /dev/video0 (or more generally /dev/videoX where X is a number) 
is the user space entry point to access the driver's V4L interface.

The driver also implements a DVB interface (when the device in question 
has a need for it... read on).  The exact path for that is completely 
different (/dev/dvb/....) and somewhat more complex, however any 
DVB-aware app will know how to find it.

And the sysfs interface is a yet third possible (nonstandard, but very 
useful) interface for controlling the device.

Physically, the pvrusb2 driver is a single driver handling a single 
device.  It just happens to implement multiple interfaces.  In an 
"ideal" world, you should be able to open any supported interface and 
have full run of the underlying device.  However in the far-from-ideal 
V4L/DVB world, the DVB interface currently only can handle true digital 
content, while the V4L interface can only handle analog content.  This 
results in the current situation where if you want to stream digital 
content you have to open the DVB interface, and if you want to stream 
analog content you have to open the V4L interface.  Thus from the view 
of any application the whole puzzle looks like 2 devices instead of one.  
But really under the hood you are actually dealing with one hybrid 
device that can do either one of digital or analog.  Any app which might 
use both interfaces (e.g. MythTV) has to know that it's dealing with a 
single device since in the end it really *is* a single device that can't 
be expected to do 2 things at once.

Just to further confuse things, you might at this moment be asking "but 
the analog side for the pvrusb2 driver is *ALSO* mpeg digital video - so 
why must that ride over the 'analog' V4L interface?"  The answer for why 
this is the case is kind of subtle.  I can go into excrutiating detail 
here, but I don't think you're going to want to hear it.  Suffice to say 
that no one single issue is a total showstopper, but it's not trivial 
either to really bring both interfaces up to parity with one another.  
Plus there's the fact that I doubt that MythTV will have any chance of 
knowing how to deal with an MPEG-TS stream coming from a V4L interface 
:-( But as I said, in an ideal world, it would be great to have equal 
access from either interface - do that and suddenly (theoretically) it 
becomes possible to do a lot more with the analog side of the device 
which right now is limited to just V4L apps that can understand mpeg 
streams - just really xawtv, MythTV and "trivial" cases which can treat 
the V4L spigot as a plain mpeg file, like mplayer, vlc, etc.  It would 
be cool for example to use a true DVB app instead to capture content 
from the s-video input.

The pvrusb2 driver only enables the DVB interface if the device it is 
dealing with has digital TV capabilities - right now that's the 
Hauppauge HVR-1900 & HVR-1950, and the OnAir Creator (and an older 
variant).  Otherwise you will just see the V4L interface showing up when 
the device is plugged in.

The pvrusb2 driver internally just implements the digital video path as 
another input choice "dtv" alongside "television", and it fully handles 
all the various bits of reconfiguration when shifting between inputs 
that cause a mode switch.  That part is seamless.  Using the sysfs 
interface you can see all the choices at once (look at ctl_input when 
nobody has either the V4L or DVB interfaces open).  However "dtv" 
doesn't work through the V4L interface, and *only* "dtv" works through 
the DVB interface.  The driver enforces this, by narrowing its list of 
allowed input choices depending on which interface is open - and if the 
result of that narrowing is the 'empty set' then it won't let you 
operate that interface (which is how the mutual exclusion is effectively 
enforced).  So you can't hurt things by trying to operate both 
interfaces at the same time.  But don't expect the second-to-be-opened 
side (either V4L or DVB) to be of much use while the first-to-be-opened 
interface is still open.

Clear as mud?


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8