Nemosoft Unv. wrote: >Greetings, > >On Friday 22 February 2002 23:24, Mark McClelland wrote: > >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. >
OV511 has the same problem. Not only are there different compressed formats for GBR/YUV 422/420 and YUV400, but there are four levels of decimation that also change the data format. A different FourCC (or whatever) could be defined for each combination, although I would much rather tack a two-byte header onto the data. The compression already employs plenty of proprietary headers, so adding a little more to make it fully self-descriptive doesn't seem so bad. I do agree that device-specific stuff should stay in the driver when removing it would cripple its functionality. >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? > Yes, unless you have some code in there that sleeps or calls schedule(). >I was under de impression it didn't matter (my system >seemed responsive as always even when the decompressor was chewing away) > I don't notice it on my dual PIII 850, but the latency was so bad on my Cyrix PR166 that I could barely even move the mouse pointer. >>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). > It can already be disabled with the "force_palette" module parameter, and the version from my website will soon have it #ifdef'd out by default. I'm not going to do it in a stable kernel. Users should never have a disincentive to upgrade their (even-numbered) kernel, especially since upgrades are often necessary for security reasons. -- Mark McClelland [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
