On 28-May-01 Oliver Neukum wrote:
>> 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.
Agreed; decompressors will remain kernel space, Iīm afraid (or, as in my
case, a module plugin).
I donīt think a camera-specific GUID is such a good idea either. Most
cameras deliver a format that looks like something defined in the V4L API,
so that can be delivering to the app, with minimal or no modification; no
need to enumerate every oddball format that comes along. Itīs just that the
apps will have to get used to a severely limited set of palettes with
webcams.
>> 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.
>
Ehm, maybe it is then time to subscribe to the video4linux mailinglist; you
would have caught this problem in time I suppose. I must admit, I have only
done so recently myself... But I agree, changing things in the middle of a
2.4 release isnīt a good idea.
BTW, I am not sure what you mean by ītoolī here. If they are user apps, they
shouldnīt be affect by a change to video_register_device(); external drivers
(like mine), would be.
- Nemosoft
-----------------------------------------------------------------------------
Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000
URL: never IRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft
>> Never mind the daylight <<
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
