On Tue, 16 May 2000, Alan Cox wrote:
> > I would suggest to modify all drivers only after 2.4 is released. It will
> > be then part of generic USB video library (which would include
> > load/unload, open/read/mmap/close, ioctl, USB data pump with color
> > transformations done in read/ioctl (V4L client) context etc. etc.)
>
> Transformations are done in user space. There should not be video or audio
> magic transforms going on in kernel space.
This is a very nice idea; however all cameras produce their own variants
of known formats; some are even compressed. The driver -must- do something
with this totally device-specific data stream. No client would be able (or
want) to understand device-dependent formats. V4L does not seem to have a
good place to insert such conversion code into. V4L2 does. In the mean
time all drivers produce RGB24 (or GRAY) output - not because they love it
but because they must.
> Also if you build support code the best way to do it is to look for
> common tail code and extract it - dont try and build some kind of
> middle layer of glue, that bites you long term as you cannot go around
> it
All (or most of) camera drivers are based on CPiA code. It did YUV -> RGB
conversion in USB interrupt thread. This is very bad performance-wise. I
experimented recently with moving this transformation into read() or
ioctl() calls to release USB "interrupt" faster - and it helped a lot;
Previously I could not decode 640x480 YUV frames on PII/400 - USB stack
just crashed (eventually) because I had to spend absurd time in USB
"interrupt"; now I can do it easily, and everything works smoothly. But
this was done in experimental code, not in 2.3.xx tree. I am still unsure
if I should update ibmcam driver at this time.
Thanks,
Dmitri
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
