[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