Re: fbvid.h feature request

[Nick K. <nic...@ma...>]

Hello, Romain!

On Sun, 13 Jan 2002 19:14:05 +0100 you wrote:

> Sorry for the late answer, been busy...
> 
I'm sorry to trouble you.
Currently I've found that I can't continue development of my driver for
Linux kernel.
Since after applying color correction algorithm it became violate rule:
"No float in the kernel" :(
So I've dropped it into userspace.

I've designed new technology - VIDIX (VIDeo Interface for *niX)
which is portable (Linux, *BDS, Solaris; Intel, Sun, DecAlpha),
much faster of X11 and uses mathematics library.
I've found a lot of fellow campaigner which currently develop new drivers
for VIDIX.

So if someone interested with it - please visit: mplayerhq.hu (CVS tree)

> > Gerd Knorr (from vid...@re...) said that ruby tree will be
> > included into Linux-2.5.x.
> 
> The tree will probably be integrated by incremental patch, not as a
> whole, and I suspect that the ioctl-oriented nature of fbvid.h will
> prevent it from being integrated in 2.5.x :-(
> 
> > In this connexion, I have some question and feature request:
> > Do you plan to expand possibility of subj?
> > I mean that existing interface lacks some possibility for fully featured
> > BES support:
> 
> [snip]
> 
> > After studying v4l2 project (http://www.thedirks.org/v4l2/videodev.txt)
> > I've found that it is more advanced against of fbvid.h. What about to add
> > some possibility into fbvid.h from this project and even more?
> 
> > I have some ideas also but what about above extensions?
> 
> Well, I'm no sure that fbvid != v4l2 :-)
> 
> fbvid is (was ?) mostly an in-house project to get overlay on the
> Permedia3, that was proposed to the community to start discussion on the
> subject of possible extension to a regular framebuffer. Your interest
> prove it was a good idea :-)
> 
> The name was probably not well-chosen... All you extensions look useful,
> but they mostly consist of adding better _video_ support to the
> framebuffer, where I only though at first of static overlay, that could
> have been used by video app to store their frames.
> 
> I didn't know v4l2 included a video _output_ API, I though that like
> regular v4l it was mostly video input. I didn't look thoroughly, but if
> a regular framebuffer driver can be extended to become a v4l2 output
> device, it might be the best way - in particular if v4l2 has an API that
> is going to be integrated into 2.5.x. If this extension is not possible,
> it migth be worth contacting the v4l2 guys and see with them what is
> possible to do. Having the FB driver registering an output device should
> be possible, in particular with devfs ; James Simmons also intend to add
> a FB filesystem in 2.5.x I believe.
> 
> -- 
> DOLBEAU Romain               | The Gods made Heavy Metal
> ENS Cachan / Ker Lann        |     and it's never gonna die
> Thesard IRISA / CAPS         |           -- Manowar,
> dol...@cl...    |    'The Gods made Heavy Metal'
> 


Best regards! Nick