On Wednesday 20 March 2002 11:16 pm, Ronald Bultje wrote: > I don't lika alsa for exactly this reason. A driver that needs a > userspace lib to function well is broken by design and implementation, > imho. They even recommend us to use the lib because some fixes for > mistakes on the driverside are in the lib side. Come on! IMHO, in the context of image capture from a camera, a driver should be "Something that delivers a GOOD image to an application". If in the kernel space image manipulation is verboten then there is no way to get a good image from all devices. You may get a good image from some, but for the majority of devices you will get something mediocre at best. Here's some of the things the webcam my v4l driver needs to get a good image to a v4l application which should not be done in the kernel: gamma correction rescale sharpen white balance The camera does none of those itself, and without them the image is bland. Not only should I not do some of those in kernel space, in some instances (gamma) I can't do them in kernel space without going down into assembly because there is not a math library available to kernel code (interestingly v4l2 has a built in divide 64 bit by 32bit number function). If a driver were broken into two pieces: a kernel portion whose only job is to get a frame of raw unprocessed data from the camera, and a user space portion whose job is to convert the raw data into a GOOD image (helped greatly by the fact that I have access to pow() in user space), then I could make the kernel purists happy by doing the lightest weight possible tasks in kernel space and the users and v4l application developers happy by delivering a high quality video stream to a v4l app. Right now I have a somewhat hacked compromise. I allow a bunch of control of the camera through the /proc interface. So the user can crank up the amount of processing done in the kernel in order to obtain that all important GOOD image.
