[MPlayer-dev-eng] Vidix Status

[Rich Felker]

On Mon, Feb 05, 2007 at 09:54:17AM +0100, Benjamin Zores wrote:
> On 2/5/07, Attila Kinali <attila at kinali.ch> wrote:
> >On Sun, 4 Feb 2007 14:22:02 -0500
> >Rich Felker <dalias at aerifal.cx> wrote:
> >
> 
> >> While we're at it, is anyone interested in making wrappers so that
> >> vidix drivers build as kernelspace modules? Running them in userspace
> >> is exceedingly stupid, requiring your movie player to run as root or
> >> else use kernel modules with root vulns (svgalib_helper).
> >
> >Alex wrote the kernelhelper module long long ago. But it never
> >really worked. I never checked why it does not. I don't even
> >know whether the vidix API is suitable for a kernel module.
> 
> Here's my opinion about kernel modules. It has pros and cons as well.
> 
> Pros:
> - would be faster than userland implementation

No, if anything it would be slightly slower, but it's irrelevant. The
only time any code executes at all is on initialization and page flip.

> - it would allow using vidix as non-priviledged user (i.e. non root)
> which would make the vidix driver the best suited implementation of a
> vo driver, as faster than XV.

Actually XV is faster if the drivers perform DMA..

> - if integrated in kernel, it would be much more famous, might
> interest more people, so more developers and maybe even manufacturers,
> which would result in better drivers.

Kernel integration wasn't what I proposed, but it is a possibility.. I
think doing it in a 'nice' way that would fit into mainstream kernel
would be a much larger project though.

> 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.

I don't think so. mga_vid does just fine.

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

This would follow if the above concern were real, but IMO it's not.

> - Also the Vidix project's goal is to provide h/w acceleration on *NIX
> and doing a kernel driver would result in a Linux only driver.

No, a Linux-only wrapper for a generic driver. Of course fbsd-only,
obsd-only, etc. wrappers would also be welcome. I'm not proposing
removing the current userspace libdha, just deprecating it except in
the case of systems where you don't have a kernelspace driver.

Rich