Greetings,

On Friday 22 February 2002 23:24, Mark McClelland wrote:
> Randy.Dunlap wrote:
> >There was a lot of discussion about 1.5 years back that most of
> >the video decompression and format conversion stuff should be
> >done in userspace, and that maybe a video conversion library
> >should be supplied to make it easier on apps.
> >
> >Isn't that still desirable?
>
> Desirable yes, but it's not really feasible yet. We would need a
> user-space framework that everyone agrees to use. Apps would request a
> format conversion from a master library, which would dynamically load a
> format-specific slave library to do the conversion. That would keep the
> master library small, yet infinitely extensible. No need to recompile
> apps either.

There are additional problems; for example, the Philips decompressor 
routines need information on the exact command that was sent to the cam in 
order to initialize the decompressor properly. Pulling the decompressor 
into user space would require extra hooks/ioctl()s for the user programs to 
acquire this information. In other words: one big mess. I agree upon the 
colour conversion stuff, but I draw the line at this low-level, 
device-specific stuff.

Besides, whether its done in kernel or user space makes little difference: 
it's still a lot of CPU cycles. Although.... before the pre-emptive stuff 
made it into the kernel, if my decompressor routines take, say 200ms, does 
that mean that no other process gets a slice until my read()/mmap() 
function returns? I was under de impression it didn't matter (my system 
seemed responsive as always even when the decompressor was chewing away)

> Good things to think about for the future, but for now we're stuck with
> this. As a small concession, I promise to remove my YUV420->BGR
> conversion code for 2.6 :)

You should have done that long ago (or rather Alan Cox, who promised to do 
that). 

 - Nemosoft

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

Reply via email to