[linux-dvb] Re: State of the API?

[Ismo.Peltonen@iptime.fi]

On Tue, Oct 01, 2002 at 04:55:33PM +0200, Johannes Stezenbach wrote:
> There's no specific plan for API changes to come, we make changes in an
> ad hoc manner when we see the need for them. This means that
> documentation will be written after the fact, if at all...

The usual.. OK, so if I need an API document, I'd better start writing :)

> The API changes were done ad hoc and should be documented when we are
> confident that they are stable. I wished that there had been more
> discussion on this list about the gory details of e.g. the changes
> to the frontend API. But it's never too late for that.

OK. I'll come with my comments in each section as I get to it. I think
better when I have at least current draft of the spec in addition to the
code. Catches lots of bugs, comparing spec to code, even when writing
both spec and code at the same time.

> However, it was our understanding that the documentation was
> going along with GPL software, and thus is itself GPL.
[...]
> To clarify the licensing, we will change the lincense for
> the API documentation to the GNU Free Documentation License (FDL,
> http://www.gnu.org/licenses/licenses.html#FDL). I will change
> the title page to say so explicitly, and add a text version
> of the FDL to CVS branch NEWSTRUCT.

The reason I wasn't certain about the licensing is that it's available
for download as a pdf, and the document itself contained no licensing
note. Now that it's explicitely stated as licensed under FDL, I don't
have problems.



On Tue, Oct 01, 2002 at 06:12:48PM +0200, Johannes Stezenbach wrote:
> At the time the API was created V4L2 had no support for DVB. Also,
> IIRC Alan Cox said he didn't like V4L2 because they did color space
> transformations in the driver instead of in user space. To us it looked
> as if V4L2 would not make it into the kernel.
> 
> OTOH, "our" API still relies on V4L for frame grabbing and video
> overlay control. There's just no need to invent something new here.
> The DVB video and audio devices only take care of controlling the
> MPEG decoder (trick modes etc.), so the functionality does not
> overlap with V4L.

Now that v4l2 is going into kernel ("integration planed for 2.5.x"
in include/linux/videodev.h), it might be better to drop dvb decoder
devices and move to v4l2. v4l/v4l2 driver is needed anyway for the
decoders, so v4l2 drivers that can handle the chips means fewer drivers
overall.
However, that's not my primary concern, and I'll leave decoder sections
in the API untouched for now.

> The DVB net device existed for quite some time, it just wasn't
> documented.

OK. So it'll get a chapter in the document.

> > However, when more than one of any of the hardware units are present, a
> > problem arises regarding whether there are direct hardware datapaths
> > from one component to another. Mainly this situation arises where
> > multiple DVB-cards are installed on a PC, but there may be other cases
> > where multiple similar components exist on hardware.
> > 
> > Therefore, it must be clear from the user point of view eg. which demux
> > components can the selected frontend feed. I don't think it's practical
> > to implement at driver level such functionality where the feed from one
> > fe (assuming a TS feed can be accessed) is drawn over bus into memory,
> > then fed (again over bus) to another hardware demux. Feeding a full TS
> > over bus (twice) requires fairly powerful hardware. And yes, modern PCs
> > are fairly powerful hardware in this context.
> 
> Some of the API changes in NEWSTRUCT try to address this, but the topic
> is quite involved and may need to be rethought when we are confronted
> with more sophisticated hardware.

I agree. I haven't seen very complex hardware configurations either,
yet. Better to get the simple (and more common) configurations working
first.

> Regards,
> Johannes


Now to the API document itself again..

The general structure consists of a coverpage, license note, toc, intro,
device APIs, kernel APIs, examples, and FDL appendix. Oh yes,
bibliography is missing completely, and might be a good place to list
the relevant standards documents.

Considering that the driver now consists of a base-driver and extension
mechanism, the kernel API will probably span several chapters, one for
each device.

I'll start working with the intro-chapter first.

1.1 and 1.2 I'll check, but probably no changes. I think it might be
good if someone at Convergence would write a short paragraph in the
History section with dates regarding submittance to TVLinuxAlliance.

Overview will have some changes, as SEC is integrated into FE, and
DVBnet is a new addition.

Device location changes - /dev/dvb/adapterX/.. and with devfs
/dev/dvb/cardX/..

Using the devices - back to that when the examples-chapter is being
written.


Any comments? I will revisit the intro chapter regarding overview and
device locations and list of devices when going through the respective
device chapter.


And no, there are no deadlines. I'll work with this as time permits.
Where should I submit patches?

-- 
-----------------------------------------------------------------
Ismo Peltonen                   Axel Digital Oy
Senior Software Architect       Yliopistonkatu 25 A
tel.dir. +358 2 512 8898        FIN-20100 Turku, Finland
mobile   +358 50 539 8697       tel. +358 2 512 8800
Ismo.Peltonen@axeldigital.fi    fax  +358 2 512 8811

-- No attachments (even text) are allowed --
-- Type: application/pgp-signature



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.