> require a stand alone vicam-specific executable to change the shutter > speed. I didn't think that was a reasonable expectation.
Is a MODULE_PARM too unreasonable? I agree that the proc interface provides a simple way to change the shutter speed, but I still think that it's a lot of code to do a small amount of work. Maybe a standalone app is too much to ask, but [personally] I'd like something other than proc. > The memory should definitely not be allocated when the camera is > initialized. I think there are a few who would throw a fit if your driver > was allocating 320*240*3*2 bytes of data (nearly half a megabyte) any time > the camera was plugged in but only got used if a V4L application started If you don't intend to use the camera, why plug it in? If you want to plug it in, why not leave the driver as an unloaded module? cp and dd are not V4L applications, but they would cause this memory to be allocated. > The V4L API also says that applications should provide a suitably sized > read buffer. An application which does this, will receive the expected V4L > behavior from my driver. An application which does not, would break on any > other camera. I'd be happy to see read replaced with something simpler > provided that it allows a user using simple shell commands to capture I submitted a patch earlier to show what I meant. I can submit another which will probably break cp but will work with any application that supplies a big enough buffer (dd works with it). Is that sufficient? > It is a V4L issue that is sorted out in V4L2. But I still rather like the I'm not familiar with V4L2, unfortunately. > fact that without using any V4L apps, a user can write a shell script and > use Image Magick to create a viewable gif/jpg/png/whatever. And I'm not opposed to it. But I think that the driver's primary responsibility should be to V4L apps, and if we can make shell utils work as a side effect, cool. But they should take a back seat to V4L. I'm willing to back off of some of this stuff if others think I'm wrong, but so far no one has spoken up. John ------------------------------------------------------- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javavote _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
