On 28-May-01 Dmitri wrote:
> Quoting Nemosoft Unv. <[EMAIL PROTECTED]>:
> 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.
Agreed; just gleuing the pieces together.
>
>> > 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.
Oh no, this would be a developers nightmare... Since it is unlikely that
manufacturers would adhere to a common format for these .so�s (because of
lack of any current standards!), every .so would have to be loaded and
treated differently. So this logic would have to be built into every
program; getting the colour conversion in will be hard enough already!
Furthermore it would mean the developers either have to collect all the
modules themselves and distribute them with the program (possibly violating
copyrights), or send their users on a hunt for the specific .so across the
planet... Mind you, you are now tying hardware specific stuff into a
program; plus such decoders probably require information they can�t get from
user space (for example, the USB ids, revision number, the current video
mode, etc).
No, this is asking for more trouble than it�s worth.
>> 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 there�s a practical way in any kernel.
> 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...
This what I�ve been saying all along... Frankly, I don�t like being wedged
into an impossible situation where my or your driver may not have some
functionality, yet the programs that use this driver don�t know how to
handle a small set of palettes.
Therefor, I would like to propose, along with other people, that this
situation is resolved in 2.5 (2.5.0 even). In the mean time, we can merge
all colour conversion stuff into a single file/module, to prevent
duplicate code.
> 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.
That API needs an update anyway (see my Developers page at my site with a
small rant of what�s missing/changed in the current V4L :))
- 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
