At 03:55 PM 10/21/2002 -0700, John Tyner wrote:
A MODULE_PARM is not too unreasonable, provided it: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.
1) Can be set at any time while the camera is plugged in. We can be a little flexible on that, but it absolutely without question must be alterable while the device is open and being used by an application.
2) A different shutter speed can be specified for each camera connected. I have four cameras. Other people have reported using as many as 8. We cannot have one parm affecting shutter speed on all 8 of those cameras. I'd also not like to limit the number of cameras that can be plugged in just for sake of shutter speed adjustment.
3) Can easily be set by the user without having to use any hex/binary math.
As previously mentioned, the average user will leave the camera plugged in whether they are using it or not unless they have some reason to unplug it (like needing the USB port). Their distribution will automatically insert the driver for the device upon detection. It is unreasonable to require half a meg per camera plugged in if that camera is not in use. It is reasonable for cp and dd to have that memory allocated because they are using the camera. Is it reasonable for cp/dd to allocate and free that memory each time they run? I think it is, but I'm not sure I free the memory on close. If not, I should.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.
I haven't had a chance to look at your patch yet, but I promise I will look at your latest one within 24 hours.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?
I think a reasonable set of requirements for read is: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.
1) Applications that read in a number of bytes equal to one whole frame, will receive subsequent frames on each read. This is keeping with the V4L spec.
2) Applications that read less than one whole frame's worth of bytes will receive fragments of a single frame until it has read one whole frame. Thus `cat /dev/video0 >mypic` will work. (I think I may have been wrong about using cp, my posts on sourceforge only indicate cat working)
I believe the current read function does this. Many months ago the first incarnation of the driver had a V4L bug that prevented mmap from working, so some applications like gqcam ended up reading from /dev/video. It worked perfectly and the read code hasn't changed since then so I assume it still does. There may be more efficient ways of accomplishing the same thing, again I'll look at your patch.
I think most just see "vicam" in the subject and skip the content :) I know I only read a fraction of all the messages flying across all the linux development lists I'm subscribed to. There just aren't enough hours in a day to read and think about them all.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.
-Joe
-------------------------------------------------------
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
