On Sun, May 27, 2001, Alan Cox wrote:
> > At the risk of being off-topic, why didnīt anybody do anything about
it
> > then? Are they deaf, donīt listen to you, or are they simply
complacent?
>
> The non USB people listened. The USB stuff tended to go via a different
> maintainer hwo wanst enforcing it.
Moi?
and JE wrote:
Actually, it's all because of legacy.
I wrote the first driver that did this, simply because I couldn't find
any clients which handled v4l correctly.
...
There isn't any conspiracy, just bad precedent.
I completely agree that YUV to RGB is bad and I shouldn't have done it
in my original driver and I shouldn't have allowed it now. It WILL be
removed from all of the other v4l USB drivers at some point.
JE
=======================================
I think that there is a lot of agreement that in-kernel conversion
is wrong, but the timing of enforcing it is causing some problems.
Alan has consistently stated that the conversions should not take
place in-kernel. From 2000-may-16 thread on [EMAIL PROTECTED]
("OV511 and videodev patches"):
<quote>
Transformations are done in user space. There should not be video or audio
magic transforms going on in kernel space....
</quote>
Same date and thread, again from Alan:
<quote>
The API is intended to dump everything in user space. Doing conversions
in kernel space is bad for applications
> All (or most of) camera drivers are based on CPiA code. It did YUV -> RGB
> conversion in USB interrupt thread. This is very bad performance-wise.
This is broken. They should be outputting YUV not RGB888 to user space.
The application (or eventually once we have all the nice kiovec stuff in)
the video card is responsible for things like YUV->RGB and scaling.
</quote>
Same date and thread, from Alan:
<quote>
General transformations are not going in kernel space. Period. If V4L2
decides to do that then V4L2 is not going to hit the kernel either.
You are right that the apps have to deal with a lot of formats, wrong to
think the kernel should be involved. Your modular transformations belong
in userspace as something like libvideotransform.a.
By putting it in userspace you make it swappable, you make it easily
updated,
you make it expandable for new formats without work, and you get to use
MMX and SSE. A lot of format conversions you want MMX for - you cant get
that in kernel space.
</quote>
2000-may-17, same thread, from Alan:
<quote>
Most clients are crap. Building the library will help them yes.
> As one of future problems I may mention one: a camera can change the
> data format when changing video size. This is not handled by V4L at all.
Actually V4L was specified to try and sort of allow for this. But you are
right we don't handle it neatly.
> break. Should we attempt this change now? Linus won't even accept such
> patch, probably. After 2.4 such work can be done safely, and it will
> probably involve transition to V4L2 as well.
Post 2.4 we are going somewhere. But that somewhere has to combine the
extended
V4L1 (stradis style) , the nice mjpeg type handling (buz) and the rather
saner format handling and some of the other v4l2 bits. On top of that add
kiovecs and raw I/O to user space pages
</quote>
2000-may-17, same thread, from Alan:
<quote>
For 2.4 I agree with the consensus here - too hard, API fixes needed.
Post 2.4 it wants doing, and we want to get the transforms into a nice
library
and fix the API issues
</quote>
So Alan, is "post 2.4" == 2.4.5 or 2.5?
~Randy
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
