There have been some conflicting messages about this
(on the linux-usb mailing list).
The thing that we have agreed on so far is to wait
until 2.5 to make the changes.
I said that Alan could probably say it better than I did,
and I probably misspoke. Upon closer inspection it looks
like the argument is for drivers delivering native (device)
data and apps must be able to do the necessary conversions
in userspace. Right now a lot of apps don't know how to
do this (or that they should do this). Part of the proposal
is to add a conversion library that apps can use.
There are drivers that deliver RBG*, BGR, YUV*, etc.
*: in various flavors.
Here are some comments from Alan Cox from the linux-usb
mailing list (thread is: OV511 and videodev patches):
May 16/2000:
Transformations are done in user space. There should not be video or audio
magic transforms going on in kernel space. Also if you build support code
the best way to do it is to look for common tail code and extract it - dont
try and build some kind of middle layer of glue, that bites you long term
as you cannot go around it
May 16/2000:
The API is intended to dump everything in user space. Doing conversions
in kernel space is bad for applications
...
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.
May 16/2000:
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.
May 17/2000:
Most clients are crap. Building the library will help them yes.
May 17/2000:
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
~Randy
> From: Russell King [mailto:rmk@arm.linux.org.uk]
>
> Dunlap, Randy writes:
> > {I,N} V4L drivers to return BGR data and not do other
> > various data conversions
> > {affects lots of apps}
>
> Err, what about capture devices that only capture in YUV422? I don't
> think kernel-mode conversion is really on either, but I would think
> it'd still be reasonable to allow the user/kernel API to be any
> format, and let the user do the necessary conversion if required.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:28 EST