[linux-dvb] v1/v2/v3/v4/v5? (was: Re: [PATCHES] Frontend kernel i2c conversion.)

[Holger Waechtler <holger@qanu.de>]

Hi Kenneth,

Kenneth Aafløy wrote:
> On Friday 23 July 2004 20:06, you wrote:
>
> > that probably depends on the general plans regarding the current CVS
> > tree and the schedule for the v4 API.
> >
> > If v4 is to be pushed to the public soonish then any work in the old
> > tree despite bugfixes and minor cosmetic changes is probably not worth
> > the efforts.
> >
> > any opinions? Johannes, what's the current state of the v4 tree? Is it
> > ready for a call to the public to port all remaining drivers and to
> > clean the internal infrastructure?
>
> You are changing the subject again. When you started to post oppinions on 
> this, I really thought you had something you wanted to contribute. But 
> really, your only goal was to hinder the work in progress. Let me know when 
> you have some patches implementing the framework you are suggesting.
>
> As soon as the linuxtv.org site is up again, I'll start working on merging 
> changes that makes the current CVS not broken again.
>
> Have a nice weekend,
> Kenneth
no, please don't get me wrong -- I did not wanted to upset you in any 
case, neither wanted I defame your work. You asked for opinions, so you 
got mine, too.

The Linux-DVB code is free software, everybody is free to develop it, 
contribute, fork, change or modify the code as he wants. If I say I see 
no sense in moving to the kernel-i2c core from the technical point then 
that's my personal and subjective opinion grown out of past experiences, 
nothing more and nothing less.

Maybe a small historical review of the driver development makes my point 
clearer and makes you understand why I think that everybody should 
rather spend his time in something useful than in "just moving code 
around from one old API to the other even older one".

The first DVB driver version (let's call it v1 from now on) was 
developed by Christian Theiss and worked for the old Siemens DVB-C and 
DVB-S cards based on the av7110 and the ves1820/stv0299. In the 
beginning it was implemented in just a single file called "dvb.c" 
containing several thousand lines of code. and a firmware blob.

The next version (let's call this v2) has been worked out for 
Convergence by the Metzler brothers together with Christian Theiss. In 
this time Nokia paid Convergence Nokia for implementing the first DVB 
API under Linux. The code became cleaner, used public, mostly defined 
APIs (internally and externally) support for the now available 
Technotrend cards which had been derived from the Siemens design has 
been added. This was the 0.9.x tree of public releases.

After several drivers had been added it became clear that a cleaner and 
more well-defined internal structure would be needed. We created the 
NEWSTRUCT branch in the CVS tree and develped there the current API 
version (v3). This work was done by the Ralph and Marcus, Johannes, 
André and me in those days. The design requirements targeted to the 
available hardware: Siemens-alike fullfeatured cards with MPEG-decoder, 
decoderless Nova-style cards and fixed-function MPEG/DVB STBs with one 
or more MPEG decoders and frontends onchip/onboard.

As soon this was done (it took a pretty long while, most of you will 
remember the time between the 0.9.4 and the 1.0.0 release where almost 
all users worked on the CVS trees - ) we felt ready for both a public 
release and merging the DVB infrastructure code into the kernel.

The following 1.x.x releases added new hardware drivers and fixed bugs, 
but both the internal and external APIs remained stable and 
backwards-compatible. We can be pretty proud of the fact that so few 
bugfix-releases had been necessairy, thanks to all the testers which 
patiently used CVS snapshots for a long time. In those days Michael took 
over kernel driver maintenance.

In discussions with STB chipset vendors and while working with the v3 
code in production environment several improvements have beed suggested 
which led to the v4 API proposals which try to make use of all features 
today's STB chipsets provide. It is thus in particular useful for STBs 
but can as well get used on PC-alike hardware (especially for STB and 
MHP developers who want to develop on their workstations instead of the 
target platform for faster turnaround cycles).

The v4 API definition is now in discussion for a pretty long time again, 
became more and more robust and is likely to get released soonish -- it 
will replace v3 then, a new major v3 release is unlikely.

So what will come thenafter, will v4 make sense for average consumers at 
all? Yes -- definitely, it's just the next step in development. What 
will come next? v5? sure. But how will it look like?

hmmm... ok -- let's remember the v3 experiences and then review the 
latest-generation hardware.

First of all v3 fits the average user's requirements pretty well. There 
are some serious maintenance problems that showed up in the past. Most 
important is probably the sensible frontend code. Most drivers care 
about multiple differently wired hardware which turned out to become a 
mess because minor changes and optimizations for one target easily broke 
the driver for another hardware (which again was rarely available for 
the developer -- there are just too many different flavours of DVB cards 
and STBs out there... not to talk about closed-source development which 
at the end financed a lot of the publicly release code and shared by 
dual-licensing some portions of the public frontend drivers).

So one big wish is to seperate drivers for seperate hardware.

The next issue is that many modern chipsets require firmware uploads to 
different parts of the hardware. There is no clean way to do this 
perfectly, the early (questionable from the p.c. point of view) dirty 
hacks worked very well - the later code loaded the firmware blobs at 
runtime which caused some troubles for the end user, browse the mailing 
list archives of the last 6 months, in some weeks roughly 25% of the 
traffic was related to this issue. So this may need some more thoughts.

Then most users don't know (and don't even want to know) what demod or 
tuner is soldered on their board. Autoprobing is hard to impossible. A 
merged per-board driver would solve this nicely, the USB/PCI/1394 bridge 
device/vendor/version ID now identifies the the frontend, too. Users 
struggling with not-loaded/loaded-the-wrong frontend driver made 
probably the 2nd most significand group of pseudo-bugreports on this list.

anything more? hmmm, don't know.

Ok... then let's review today's bleeding edge hardware. Fullfeatured 
cards are dying out. Microsfot does not even supports them in their BDA 
infrastructure for DVB cards.

High-end STB processors don't have fixed-function MPEG processors 
anymore. The users want to decode HDTV, MPEG4, DivX, some providers ask 
for proprietary formats like RealVideo and the Microsoft codecs. DVB-H 
for mobile devices does not specifies MPEG as codec at all. Implementing 
something flexible as this is only possible using DSPs or 
general-purpose processors.

The only real DVB-specific thing left in these environments is one or 
more FIFOs with a serial or parallel stream interface to the outside 
(sometimes MPEG-only, sometimes shared with a CCIR656 camera interface) 
and a DMA-interface to the host. I know at least 3 processors realizing 
this setup available today (though they're not yet as cheap as 
fixed-function chipsets, the development is comparable to graphics 
processors, programmable hardware comes slowly but it comes - ).

This setup is pretty similiar to the one of today's Nova-, Budget-, 
Skystar- and USB- adapters. So what API do we need to suit them well?

Basically a DVB device is now becoming nothing more than the (often 
hotplugged or switched with the camera-I/F) frontend and a FIFO which we 
want to mmap() in memory to synchronize DMA transfers.

So most probably v5 will look like this: the userspace frontend API 
looks similiar to the one we have today in v3 and v4. Minor changes will 
follow the available hardware capabilities. In Opposition to Microsoft 
we support any number of DVB devices and DiSEqC2.x from the first day on 
(we do it already - ;).

The new thing is that the user can call mmap() on the frontend file 
descriptor and will get the raw transport stream like from today's dvr 
devices.

We don't have any software fallback code in the kernel anymore, this one 
was considered as dangerous and prone to bugs some times. Maybe we will 
provide an ioctl for simple PID filtering (this is supported by some 
demods and can as well get implemented in DMA state engines for some 
hardware but is not mandatory, it will only get used as hint to safe bus 
bandwidth).

The entire device handling, dmxdev/dvrdev, networking, and i2c code in 
dvb-core can vanish completely.

DVB-Networking code is implemented as userspace deamon which feeds a 
network-loopback device.

A dvb driver can export it's i2c bus to the kernel (if it has one to do 
so and the driver developer feels bored:) but it does not needs to. 
Drivers for cards with onboard-uCs can talk the highlevel-protocol to 
their demod devices directly. The end-user does not needs to know which 
demod chip is soldered on his board, he does not needs to know whether 
it's an old i2c-controlled metal-can, an old 3-wire-bus controlled PLL 
or a brand-new SPI-controlled silicon tuner. If i2c demod drivers are 
using the kernel i2c API they are only allowed to attach to the bridge 
with their parent card's vendor/device ID.

OSDs and video graphics are rendered using commonly available APIs like 
DirectFB, OpenGL or OpenGL-ES.

Section-filtering, MPEG2/4/DivX/whatever decoding and rendering is 
implemented in userspace either using a library like ffmpeg or the 
(usually) binary-only firmwares and libraries provided by the chipset 
vendors.

Now a v5 driver looks basically like a cleaned and stripped-down 
frontend driver (it is written for exactly one flavor of a particular 
hardware), the dvb-core only provides some helper functions that 
simplify the mmap() and device registration implementation (i'm not sure 
if this is needed at all, maybe the device.h API is enough - ). That's all.

Ermm.... and what did I wanted to say? v4 is already knocking on the 
doors, v5 is pretty close to v3 and thus not far away (for those who are 
interested: we developed a userspace-only driver using the libusb 
following roughly these ideas for a DVB-T device in roughly 400 lines of 
code, a kernel driver won't take much more efforts. We'll probably 
release this code this autumn).

Everyone is free to work on the old code as he likes, but it's a pity 
about every effort that does not fixes bugs, does not introduces support 
for not-yet supported hardware but only new instabilities and troubles 
to the end-users. The time could better get spent into finalizing the v4 
implementation and/or thinking about v5.

So do whatever you want - it's free software and you're a free man. But 
please don't complain thenafter that you have not been warned: your work 
might be of little duration...
;)

Holger