[mythtv] IVTV VBI reading

[Hans Verkuil]

On Saturday 20 January 2007 15:34, Daniel Kristjansson wrote:
> 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.

I think I would prefer that VBI is off by default for anything but the 
latest drivers (>= 0.10.0). If someone wants it for older drivers, then 
that is still possible. Completely removing it is overkill, I know that 
some people are using it to their satisfaction.

> > > > 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.

I thought you meant the removal of the numeric ioctls. Sorry for the 
misunderstanding.

It will definitely be possible to test for the new ioctls using the ivtv 
version with QUERYCAP. I will almost certainly move to version 1.0.0 or 
something like that once the driver is merged into the kernel.

>
> > 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 :)

I'll ask him gently :-)

>
> > 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

Thanks!

	Hans