Quoting Nemosoft Unv. <[EMAIL PROTECTED]>:
> 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.
Not really; the common interface is split into two parts - one that
extracts the data from the physical device, and another that processes
that data to make it into whatever you requested. The interface at the
user endpoint (an API) would be the same for all cameras. Common interface
does not need to be a one-piece monolith.
> > Furthermore you are unlikely to have that library for compression formats
> > are secret in many cases.
Not at all. Manufacturers will be able to distribute the
libSecretDecoder.so file along with opensourced kernel portion, if
the latter is needed at all. If the decoder is missing then decoded
modes become unavailable; this provides something working on
officially unsupported hardware.
> Agreed; decompressors will remain kernel space, I?m afraid (or, as in my
> case, a module plugin).
In 2.4 there is no other practical way.
> 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.
This is often not good enough. My driver, for example, does not work with
some videoconferencing apps which demand some flavor of YUV. There are
tens of those. I can not possibly stuff these decoders into the driver,
and app developers don't worry about the issue because their BTTV card
works just fine...
> >> 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.
Yes, that would be one way to do it :-) But I know many people who are
not Linux hackers but just developers in commercial companies. They do
not subscribe to obscure mailing lists; all they want is a printed
document describing API.
> 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.
Kernel-space components (drivers) for proprietary hardware. I personally
know several people who write drivers; some use CPiA model and one uses
usbvideo. They all are out of luck.
When an API has to be changed it should be extended instead. That's why in
Windows API you see all these ReadFileEx() instead of ReadFile(). MS
wants backward compatibility. Later you can obsolete ReadFile(), when a
safe and tested alternative is in place. Ther would be no harm in adding
video_register_device_Ex(a,b,c) { ... }
and providing a backward compatibility wrapper
#define video_register_device(a,b) video_register_device_Ex((a),(b),-1)
Dmitri
--
It's now safe to turn your computer on."
PGP signature
