> 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.

This defeats the purpose of a common interface.
Furthermore you are unlikely to have that library for compression formats
are secret in many cases.

> 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.

And this is in kernel only. What you are describing is essentially dumping 
V4L.

        Regards
                Oliver

_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to