Hans Verkuil wrote:

It is my general impression that the 0.3 series ivtv driver has become quite
stable by now. The major lacking feature, sliced VBI for the PVR150/500, is
to be added soon. This allows the recording of closed captions and things
like that. The only other change that I might make (pending some research
first) is to use a more standard format instead of the ivtv-specific format
currently used for the VBI data (the DVB standard).

After that I propose to start the work towards eventual kernel inclusion.
It starts to become a major bother having to support the various kernels
from 2.4 upwards, and so I suggest that we take the following actions:

1) After the two features I'm working on are added we freeze the 0.3 series,
  except for (serious) bug fixes. This becomes the stable release, replacing
  the 0.2 series.
2) Start a new 0.4 series with the goal of being included in the kernel.

I think we need to do the following in order to become 'mainstream':

- First merge any relevant ivtv changes to tveeprom.c, tuner.c, msp3400.c
 and tda9887.c to the v4l sources so that we can stop keeping our own
 copy around. I'm working on this already.
- Move the supporting modules (saa*, cx* and wm*) to the v4l repository,
 again for inclusion with the kernel.
- Drop support for the 2.4 kernel and possibly older 2.6 kernels (not sure
 what the v4l policy is) in ivtv.
- Get the v4l2 sliced VBI API from draft to final based on the work done in
 the ivtv driver. (I'm working on that)
- Drop the ivtv-specific sliced VBI API and replace with the v4l2 final API.

This should be a good moment to release a stable 0.4 version and open a 0.5
series for the next steps:

- Clean up the ivtv sources to make them even remotely acceptable for the
 kernel. Ouch.
- Document some of the darker corners of the driver. Double ouch.
- Start the process of moving the driver into the kernel.

So the 0.3 series will have to be maintained occasionally until the 0.4
series is ready. Then we can stop maintaining 0.3 and start maintenance
on 0.4, which should be easier since we now only have the ivtv module
itself to maintain, the remainder should be in the v4l repository or even
in the kernel. So we can tell people that they should upgrade :-)

0.5 is purely work to get it in a state that you don't feel too ashamed
when you give it to Linus :-)

I think this covers it pretty well, any comments?

                Hans


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ivtv-devel mailing list
ivtv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ivtv-devel


Sounds like a great plan to me, I'll be able to give info on any internal parts since have dug through and deciphered most parts of the code in the past at some time, just takes a few minutes sometimes to get familiar again with each separate part, the whole thing is quite a complex module having so many functionalities wrapped up in one chip (like 5 chips/drivers in one all doing intense DMA work within the same memory and DMA controller). You have YUV/PCM/VBI/Radio Capture, MPEG2/MP2/VBI encoding, MPEG2 Display with OSD overlay, YUV decoding with OSD overlay. And those activities can all run simultaneously, yet all using the same registers for DMA xfers and not separate chips for the main API interaction. I could be sent lists of questions possibly and answer them as I have time to dig out details which are things I dont' obviously think of off hand that are odd parts of the driver not easily understood what is completely going on.

Thanks,
Chris.

Thanks,
Chris

--
===
Chris Kennedy
[EMAIL PROTECTED]



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ivtv-devel mailing list
ivtv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ivtv-devel

Reply via email to