[MPlayer-dev-eng] Vidix Status

[Attila Kinali]

On Mon, 5 Feb 2007 09:54:17 +0100
"Benjamin Zores" <ben at geexbox.org> wrote:

> Here's my opinion about kernel modules. It has pros and cons as well.
> 
> Pros:
> - would be faster than userland implementation

Actualy no. Switching into kernel space always involves
some overhead. Doing everything in user space is faster.
But this overhead is so little, that it doesn't hurt us at all
(only a few dozen calls per second with long execution times per
call)

> Now for the cons:
> - Whatever one can say, vidix is not what i would call an active
> project and the kernel API is evolving A LOT ! This seems that it
> would require a constant maintainership in order to allow us to
> maintain the driver over kernel releases.

Not really. The times when the driver model changed with every
release are over. I assume that the vidix kernel driver would
need about the same subset of the kernel API which is very
stable these days (just check the mga_vid svn for API fixes)

> - The only way to do that would then to write drivers expecting them
> to be included in main kernel line.

That would be ultimately the goal, but it takes some time.

> What I'd like more to see in vidix (whether it is in user or kernel
> space) is a way
> to handle more than overlay (i.e the GPU decoding capabilities, like XVMC does).

I'd actualy like to see a generic graphics API in the kernel
similar to ggi, but more generic and not so complicated.
My midterm plan is to implement something like this while
writing the OGP driver, but currently i have so little free
time that i couldnt even check what kind of APIs are around.

			Attila Kinali
-- 
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
                         -- Deed of Morred