Quoting Alan Cox <[EMAIL PROTECTED]>:
> > routines, while (nearly) nothing has been said about other (USB) webcam
> > drivers which have conversion routines.
>
> I have those in my firing line too. It has always been the policy that format
> conversions go in user space.
To accomplish this noble goal we need a new V4L API that has not one but
two components. The kernel portion sits in kernel space (maybe) and
sucks the data out of the camera. The userspace portion postprocesses
the raw data and provides a standard interface to user apps.
Currently, there is no such "bottom half" component, and there is not
even a place to insert it. The V4L interface ends at /dev/videoX. Any
attempts to insert (link) a device-dependent library into tens of
video apps have to be based on very well documented new interface, and
a shared library (or something else) to access raw devices, interrogate
them in details, match formats etc.) Among that is the question
how do we extend and maintain this library because the kernel driver and
the decoding/converting portion of this new library are closely tied,
and change in one will likely require change in another. But kernel and
userspace stuff are maintained separately!
As it stands now, V4L does not provide any means to move the conversion
into userspace. Many cameras even have different "native" formats in
different modes and on different image sizes. IBM cameras, for example,
usually stream something resembling YUV but not exactly that. The
conversion library will need to know most intimate details about the
datastream being processed.
If converters are removed from drivers before new V4L is created and
tools migrated then everything breaks. A replacement V4L stack must
be first agreed upon, created and all drivers rewritten for it; only
then the old solution can be obsoleted. I can't see how removal of
thousands of lines of code can help here. They are all modules, after
all.
Thanks,
Dmitri
--
A horse! A horse! My kingdom for a horse!
PGP signature
