Mailing List Archive: ivtv: devel

ivtv TODO list

Index | Next | Previous | View Threaded

hverkuil at xs4all

Jan 18, 2010, 10:35 AM

Post #1 of 6 (1796 views)
Permalink

ivtv TODO list

Hi all,

At the beginning of the year when I passed the maintainance of the ivtv driver
to Andy I promised to write a TODO list. Well, here it is. I think I have all
the important items, but I'll reply to this message if I think of others in the
future.

There is no particular order to these items. Most of these are hard or time
consuming to do. Otherwise I'd have done them by now :-)

- Both cx18 and ivtv use IRQF_DISABLED when registering the irq. This flag is
bogus (and produces this annoying message in the log: 'IRQF_DISABLED is not
guaranteed on shared IRQs'). Note that many drivers do this. This is something
I discovered only recently.

- Currently a private 'ivtv' format is used to store VBI data in an MPEG stream.
I know that there is a standard format that can be used to store info like
this in an MPEG stream and that should make this more compatible. I know I
looked at this in the past, but I decided against it at the time because the
total size of the VBI payload could be more than the maximum size supported
by the cx23415 MPEG decoder. It's not a problem to write larger packets, but
the MPEG hardware decoder will truncate it internally.

In hindsight I should have gone with the standard anyway since I don't think
this will be a problem in practice.

- NTSC and WSS. I still do not know how NTSC determines whether the source is
4x3 or 16x9. PAL uses the WideScreen Signal (WSS). A similar feature exists
for NTSC, but it is unclear whether it is actually used by broadcasters.
Nobody seems to know.

- Replace the PCM device node with a proper ALSA device.

- Work is underway to add a V4L2 event API. When done ivtv should add support
for this. It currently uses an event API that actually is part of the DVB
API and that API is poorly designed.

- The xf86-video-ivtv X driver should really be merged with the other X drivers.

- Implement videobuf to support proper IO streaming for the raw YUV device
nodes.

- I wrote an ivtvtv utility to be able to test some of the more advance capture
and decoding features of ivtv. (http://www.ivtvdriver.org/svn/ivtvtv/trunk)
It would be really nice if that could be cleaned up and possible moved to
the v4l2-apps directory of the main v4l-dvb repository.

- For that matter, I think the last remaining utilities should either be
removed or cleaned up and moved to v4l2-apps. Most of them are fairly
generic already.

- I am not sure whether there is much point in ivtv-devel these days. It should
perhaps be closed down and we can just keep ivtv-users.

Please don't hesitate to reply to this post if you have more ideas!

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

dheitmueller at kernellabs

Jan 18, 2010, 10:42 AM

Post #2 of 6 (1719 views)
Permalink

Re: [ivtv-users] ivtv TODO list [In reply to]

On Mon, Jan 18, 2010 at 1:35 PM, Hans Verkuil <hverkuil [at] xs4all> wrote:
> - NTSC and WSS. I still do not know how NTSC determines whether the source is
> 4x3 or 16x9. PAL uses the WideScreen Signal (WSS). A similar feature exists
> for NTSC, but it is unclear whether it is actually used by broadcasters.
> Nobody seems to know.

The reality is that for NTSC there is no standard. There is an NTSC
variant of WSS discussed in the WSS specification, as well as a way of
representing the info in EIA-608. As far as I have been able to
gather though, neither have actually ever been used in production. If
someone wants to offer some evidence to the contrary, I would be happy
to add the support to tvtime and test it with some of my tuner boards
(and fix any bugs that in the driver I find).

> - Replace the PCM device node with a proper ALSA device.

For what it's worth, this has actually been done for the cx18 (but not
for ivtv). I just need to do the final PULL request to get it into
the mainline v4l-dvb.

Cheers,

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

awalls at radix

Jan 18, 2010, 12:33 PM

Post #3 of 6 (1713 views)
Permalink

Re: ivtv TODO list [In reply to]

On Mon, 2010-01-18 at 19:35 +0100, Hans Verkuil wrote:

> There is no particular order to these items. Most of these are hard or time
> consuming to do. Otherwise I'd have done them by now :-)
>
> - Both cx18 and ivtv use IRQF_DISABLED when registering the irq. This flag is
> bogus (and produces this annoying message in the log: 'IRQF_DISABLED is not
> guaranteed on shared IRQs'). Note that many drivers do this. This is something
> I discovered only recently.

I naively asked near the end of this discussion on the LKML what is the
preferred solution to fix the "problem":

http://lkml.org/lkml/2009/11/30/486

No one answered. The whole thread was about the problem with
IRQF_DISABLED not being honored and the need to run with interrupts
disabled.

As I understand it, the IRQF_SHARED with IRQF_DISABLED problem is really
a problem in the kernel's management of interrupt handlers and has been
labled as "do not fix". Hence we have a useless message being printed
out, warning users of a condition that has been in existence long before
the message existed, for which there is no agrred upon solution in
sight. The user can't fix it short of moving hardware around. I'm
pretty sure a driver can't fix it without either:

a. refusing to work at all (no good for users)

or

b. running it's IRQ handler with interrupts enabled (no good for
multimedia capture devices, you'll just drop frames for no good reason)

So there the warning message sits.

Did I get it wrong?

Regards,
Andy

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

hverkuil at xs4all

Jan 18, 2010, 1:09 PM

Post #4 of 6 (1716 views)
Permalink

Re: ivtv TODO list [In reply to]

On Monday 18 January 2010 21:33:09 Andy Walls wrote:
> On Mon, 2010-01-18 at 19:35 +0100, Hans Verkuil wrote:
>
> > There is no particular order to these items. Most of these are hard or time
> > consuming to do. Otherwise I'd have done them by now :-)
> >
> > - Both cx18 and ivtv use IRQF_DISABLED when registering the irq. This flag is
> > bogus (and produces this annoying message in the log: 'IRQF_DISABLED is not
> > guaranteed on shared IRQs'). Note that many drivers do this. This is something
> > I discovered only recently.
>
> I naively asked near the end of this discussion on the LKML what is the
> preferred solution to fix the "problem":
>
> http://lkml.org/lkml/2009/11/30/486
>
> No one answered. The whole thread was about the problem with
> IRQF_DISABLED not being honored and the need to run with interrupts
> disabled.
>
> As I understand it, the IRQF_SHARED with IRQF_DISABLED problem is really
> a problem in the kernel's management of interrupt handlers and has been
> labled as "do not fix". Hence we have a useless message being printed
> out, warning users of a condition that has been in existence long before
> the message existed, for which there is no agrred upon solution in
> sight. The user can't fix it short of moving hardware around. I'm
> pretty sure a driver can't fix it without either:
>
> a. refusing to work at all (no good for users)
>
> or
>
> b. running it's IRQ handler with interrupts enabled (no good for
> multimedia capture devices, you'll just drop frames for no good reason)
>
> So there the warning message sits.
>
>
> Did I get it wrong?

The problem with IRQF_DISABLED is that it disables all interrupts. We don't
need that. And while you are in an interrupt handler you can be sure you
won't be interrupted again with the same interrupt (so no nesting). So what's
the point of IRQF_DISABLED in the first place? From what I've read there
should be no reason to set this flag anymore except in some rare cases to do
with timers (Linux Device Drivers, 3rd edition, page 268, Fast and Slow Handlers).

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

jra at baylink

Jan 18, 2010, 1:14 PM

Post #5 of 6 (1716 views)
Permalink

Re: ivtv TODO list [In reply to]

----- "Andy Walls" <awalls [at] radix> wrote:
> On Mon, 2010-01-18 at 19:35 +0100, Hans Verkuil wrote:
>
> > There is no particular order to these items. Most of these are hard
> or time
> > consuming to do. Otherwise I'd have done them by now :-)
> >
> > - Both cx18 and ivtv use IRQF_DISABLED when registering the irq.
> This flag is
> > bogus (and produces this annoying message in the log:
> 'IRQF_DISABLED is not
> > guaranteed on shared IRQs'). Note that many drivers do this. This
> is something
> > I discovered only recently.
>
> I naively asked near the end of this discussion on the LKML what is
> the
> preferred solution to fix the "problem":
>
> http://lkml.org/lkml/2009/11/30/486
>
> No one answered. The whole thread was about the problem with
> IRQF_DISABLED not being honored and the need to run with interrupts
> disabled.

I have heard it said that some developers appreciate a reminder if an LKML
conversation about their hobby horse seems to be passing them by. Without
my reading the whole thread, is such a target apparent?

Cheers,
-- jra

--
Jay R. Ashworth Baylink jra [at] baylink
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Start a man a fire, and he'll be warm all night.
Set a man on fire, and he'll be warm for the rest of his life.

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

awalls at radix

Jan 18, 2010, 1:35 PM

Post #6 of 6 (1715 views)
Permalink

Re: ivtv TODO list [In reply to]

On Mon, 2010-01-18 at 16:14 -0500, Jay R. Ashworth wrote:
> ----- "Andy Walls" <awalls [at] radix> wrote:
> > On Mon, 2010-01-18 at 19:35 +0100, Hans Verkuil wrote:
> >
> > > There is no particular order to these items. Most of these are hard
> > or time
> > > consuming to do. Otherwise I'd have done them by now :-)
> > >
> > > - Both cx18 and ivtv use IRQF_DISABLED when registering the irq.
> > This flag is
> > > bogus (and produces this annoying message in the log:
> > 'IRQF_DISABLED is not
> > > guaranteed on shared IRQs'). Note that many drivers do this. This
> > is something
> > > I discovered only recently.
> >
> > I naively asked near the end of this discussion on the LKML what is
> > the
> > preferred solution to fix the "problem":
> >
> > http://lkml.org/lkml/2009/11/30/486
> >
> > No one answered. The whole thread was about the problem with
> > IRQF_DISABLED not being honored and the need to run with interrupts
> > disabled.
>
> I have heard it said that some developers appreciate a reminder if an LKML
> conversation about their hobby horse seems to be passing them by. Without
> my reading the whole thread, is such a target apparent?

My parser broke on your question.

However, this part of the discussion by Tom Glexiner (the RT Linux guy)
asks what I think are the right questions:

http://lkml.org/lkml/2009/11/30/215

That said, now I'm going to go back and read the whole thread just to
come back up to speed on all the issues.

Regards,
Andy

> Cheers,
> -- jra

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads