At 11:34 AM 10/21/2002 -0700, John Tyner wrote:
Mine wasn't the first V4L driver to support this type of functionality. Using the current mechanism, a user needs nothing more than "echo" to change the shutter speed. Using a custom IOCTL, the user would require a stand alone vicam-specific executable to change the shutter speed. I didn't think that was a reasonable expectation.> You're actually looking at a bug there. The proc interface for the shutter > (which you don't seem to like) should be setting needsDummyRead. As theWell, that makes more sense. I'm not against what the proc interface is trying to achieve so much as the way it is achieved. It takes quite a bit of code (setup, parsing, etc) to create an interface that would probably be better provided through an ioctl if at all possible.
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 up. The only appropriate single place for this I would think in open (assuming that mmap cannot possibly be called before open). Thus scrubbing the allocation from mmap would clear up this issue.> In both places, framebuf is only allocated if it is not already > allocated. I think in both places the allocation is protected by a > semaphore. Maybe it is wrong, could you give you more info? It's not wrong, per se. IMO, it's bad style. The memory should be allocated in one place when the camera is initialized (or perhaps even in the mmap call since it may not be needed until there (mine needs it before then)). The fact that you allocated it twice could lead to a memory leak if you were to ever accidentially overwrite your pointer.
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 images from the camera. I think it is a benefit to users to be able to capture images with a shell script from the webcam and not be required to use a V4L tool.Two things, the V4L API states that each successive call to read should return the next image from the device. There isn't really a need to support multiple reads over the same frame (though it is nice to the user :) ). Second, I understand what you're trying to achieve and still think that read is more complicated than it needs to be. I can submit a patch showing what I think it should be.
If we're really concerned about well behaved V4L drivers, both of our drivers should be discarded. They both violate at least two of the "well behaved" requirements.
There are no V4L ioctl's that map to shutter speed. I only mapped "gain" to "brightness" because everybody else does to the point that some applications (such as gqcam) use this in an attempt to auto adjust exposure. The range on the shutter is 4 to 31500, not many applications have controls with that much range if I were to map it to something like "contrast".> I don't mind the proc interface going provided that there is a way to > change the shutter speed independently for every camera connected. I have Is it possible to add it to an ioctl or perhaps one of the existing ones? (This is probably a V4L issue.)
It is a V4L issue that is sorted out in V4L2. But I still rather like the 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.
I can send you the latest version of my working copy (I still play with it some as a hobby), and you're welcome to use it as a guide to the async urbs if you so desire. I'll also try to assist if I can provide insight into what I did to make it happen. I just can't be the one to "take the lead" on this issue.
Sounds reasonable to me.
Any patches are welcome.Oliver hammered me pretty hard :) to get my disconnect handling into shape. As time allows, I think I'd be a little more willing to look at and try to fix that part up.
-------------------------------------------------------
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
