[mythtv] IVTV VBI reading

Daniel Kristjansson danielk at cuymedia.net
Sat Jan 20 14:34:39 UTC 2007


On Fri, 2007-01-19 at 17:36 +0100, Hans Verkuil wrote:
> On Friday 19 January 2007 15:51, Daniel Kristjansson wrote:
> The usage of VBI should be turned off by default. It doesn't matter 
> whether the VBI is embedded or read straight from /dev/vbi, for the 
> hardware it's all the same.
> 
> Non-buggy VBI will be available in ivtv drivers with version number 
> (obtain with VIDIOC_QUERYCAP) >= KERNEL_VERSION(0, 10, 0).

Ok, I'll just disable captions unless it passes this test,
that will avoid the 0.2 ioctl VBI ioctl as well.

> > I'll fix this, it's just a hangover from frame buffer recording
> > profiles. I always change this to 720x480 when I set up a MythTV
> > machine.
> Much appreciated!

I have a patch with this that I'm running locally. I just
created a ticket with the patch here:
  http://svn.mythtv.org/trac/ticket/2954


> > #define IVTV_IOC_PAUSE_BLACK     _IO  ('@', 35)
> > #define IVTV_IOC_STOP            _IO  ('@', 36)
> > 
> > #define IVTV_IOC_S_VBI_MODE      _IOWR('@', 35, struct
> > ivtv_sliced_vbi_format) /* old ioctl */
> > #define IVTV_IOC_G_VBI_MODE      _IOR ('@', 36, struct
> > ivtv_sliced_vbi_format) /* old ioctl */

> Ouch, that's old! The IVTV_IOC_G/S_VBI_MODE are used in pre-ivtv-0.4 
> versions. Newer versions from ivtv-0.4 onward use the v4l2 sliced VBI 
> API to specify which VBI types should be captured. The V4L2 sliced VBI 
> API was introduced in kernel 2.6.14. It is pure luck that MythTV works 
> with ivtv-0.4: if you turn on VBI embedding and no sliced VBI types are 
> selected, then ivtv defaults to CC for NTSC and the wide screen signal 
> for PAL.

We use the V4L2_CAP_SLICED_VBI_CAPTURE ioctl if IVTV_IOC_S_VBI_MODE
ioctl fails. But considering the problems I'll just drop support
for captions unless the user is using the latest drivers. This
isn't in the patch yet. I want to test the changes for this
against the new drivers.
 
> > > The problem is that with newer drivers I 
> > > still need to check for these old ioctls to prevent them from being 
> > > (mis)handled by the v4l2 subsystem. These checks WILL disappear once 
> > > ivtv enters the kernel. So I would appreciate it very much if this 
> > > header could be updated.
> > Will there be some way to detect the non-backward compatible
> > drivers? We will have to treat it like the V4L vs. V4L2
> > transition and will need some way to detect which API to
> > use...
> 
> Why would you want to check for this? Once you drop the numeric ioctls 
> it will work fine for all versions from 0.2.0 onwards!
>
> BTW, just to inform you: once ivtv-0.10.0 is done I will proceed with 
> the final step that is needed to get ivtv into the kernel: the 
> ivtv-specific MPEG decoding API will be redesigned into a full V4L2 
> MPEG decoding API. There are also still a few remaining ivtv-specific 
> MPEG encoding ioctls, those too will be converted (most likely).

But if these ivtv-specific IOC's change it will affect us since
we will be using them... We also try to support drivers until
they are 2 years old. I don't my dropping support for something
auxiliary like captions, but I don't want to drop support for
basic recording.

> Ian Armstrong has been doing a lot of work lately in improving the 
> framebuffer device for the OSD (used by the PVR350). It is unlikely at 
> this stage that the few ivtv-specific OSD ioctls will be converted to 
> the V4L2 API. They will probably be improved a bit, but nothing big. 
> Almost all OSD functionality can be accessed with the linux framebuffer 
> API.

Unfotunately the PVR-350 output support in MythTV is completely
unmaintained, if this stops working we'll probably just drop
PVR-350 output support. It's already pretty broken. (Unless Ian
wants to write some patches :)

> Anyway, the API changes will become effective once the driver is merged 
> into the kernel (2.6.2x were x >= 2 :-) ).
> 
> I know it will be a hassle for MythTV, but at least the good news is 
> that the new API will be V4L2 compliant and is no longer tied to a 
> single hardware platform.

Yep, I'm quite happy with the kernel merge. Once a kernel
with ivtv support has been out a couple years we can get
rid of all the ivtv specific calls in MythTV !

-- Daniel



More information about the mythtv-dev mailing list