Hi all,
I thought that it might be a good idea to give a sort of progress update
on what's happening with the driver. It's been a very busy last two
weeks for me so there haven't been many updates (although I did manage
to release 0.4.1).
Two main projects are merging support for the Japanese cards into ivtv
and adding support for the Hauppauge A/V cable set (extra S-Video and
composite inputs). These new features will only appear in the 0.5
series, not in 0.4. Both projects require a fairly big rework of
ivtv-cards.c, most of which is done. I think it will be quite an
improvement and makes adding new cards easier.
I'd like to thank Jesse Guardiani for getting me the cable set and
apologize that it takes longer than expected to get the code in. A
quick patch wasn't enough in this case (at least not without making a
big mess).
Regarding the merge of the Japanese 'paken' version: the v4l repository
now contains code to fully program the tda9887 and I'm working on
adding the necessary code to the saa7115 module to support one of the
Japanese cards that uses a different method to setup the audio clock
frequency. The changes in ivtv-cards.c should also make it easier to do
the merge for the new cards. I've fully cleaned up the wm8739.c module,
but I still have to do the same cleanup for the other new modules. This
merge has high priority for me and I intend to work on it next week.
One outstanding problem (ticket #37) is with automatically detecting i2c
chips. The current i2c subsystem in the kernel assumes that all chips
can be detected. Unfortunately this is not always the case. One very
good example are the wm8775 and wm8739 chips: they are write-only, so
there is no way to read some register to check the value it contains.
They also both use the same i2c address. There is no solution to this.
But work is being done by the i2c programmers to change this and it is
expected to appear in 2.6.16 or 2.6.17. Until that time we have to live
with it. A workaround exists using module options.
Ticket #49 is still a major bug (after a DMA error the byte stream is
shifted). There is a workaround (see the ticket) but for a real fix I
want to wait until I start the cleanup of the ivtv code. The process of
cleaning up the code may well automatically point to the fix.
The cleanup is sorely needed: I think that a 20-40% reduction in code is
possible as there is a lot of duplicate code and probably also dead
code. We have about 600 kilobytes of source code, which is simply
ridiculous (about 1/6th of the whole v4l repository!). I have to admit
that I don't mind refactoring code. It gives a special sort of
satisfaction if you can delete major pieces of code.
I don't dare give a date when the ivtv driver might enter the kernel. It
depends entirely on how quick (or not) the cleanup will be. And besides
the ivtv work I'd also like to do some work on the v4l code (esp.
msp3400.c, work together with the other v4l developers to create a
common API to set MPEG encoding properties, possible partial merge with
other projects like pvrusb2, dvb cards using the blackbird design).
One thing is for sure: I won't be bored.
Anyway, I think this gives a fairly complete (if rambling) overview of
what's cooking.
Merry Christmas!
Hans Verkuil
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
