Quoting Oliver Neukum <[EMAIL PROTECTED]>:
>
> > 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.
> >
>
> But please not in the middle of a stable series.
> IMHO this applies to to drivers that have a large user base, too.
I also vote not to remove conversion from existing drivers in the
existing 2.4 tree. These drivers are in -production- kernel, and
people are not supposed to upgrade (more like "develop"!) their
video tools (which may be as complicated as xrealproducer!).
For the latter you simply can't get any upgrades in a reasonable
time frame, and this puts the user between the rock and hard place.
There is no physical harm done to anyone because several modules -
which get loaded only by people who need them - contain about 100
extra lines of code.
Maybe the amount of fluff is even less than that, ibmcam converter
to some standard YUV format would be exactly of the same size as
currently converter to RGB is. That is because the image comes from
some cameras interlaced (only half of scan lines), and because the
YUV packing method wildly differs between cameras.
The "clean" solution is known: to restrict the driver to actually
getting the data from the camera and then dumping it into the user
space, labelled with some camera-specific GUID. Then the library
in userspace can open the stream, match the GUID to list of known
decoders, and decode the -raw- data into whatever the user wants.
But this, complete and clean, solution, is unthinkable in 2.4 - as
I said, 2.4 is released and many people depend on it. Companies
release video tools and write video drivers for 2.4 - they will be
quite upset if the rules of the game change in the middle of the game.
Even a minor V4L API change (?) - a third parameter to the
video_register_device() - broke usbvideo CVS as soon as 2.4.5 with
this change became available. There are -very many- tools built
privately, outside of kernel tree, and now they all are broken.
Granted, not a big deal to add -1 as 3rd parameter, but you must
spend your time to hunt it down. 2.4 tree is not for experiments,
in my opinion. Bug fixes and new drivers are OK to add there, but
not new versions of very popular APIs.
Dmitri
--
panic("CPU too expensive - making holiday in the ANDES!");
(Panic message in the kernel.)
PGP signature