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 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
