Hi, <snip>
OK, another example. The cameras supported in camlibs/jl2005c do not have webcam ability, but someone could at any time design and market a dualmode which has in stillcam mode the same severe limitation. What limitation? Well, the entire memory of the camera must be dumped, or else the camera jams itself. You can stop dumping in the middle of the operation, but you must continue after that. Suppose that you had ten pictures on the camera and you only wanted to download the first one. Then you can do that and temporarily stop downloading the rest. But while exiting you have to check whether the rest are downloaded or not. And if they are not, then it has to be done, with the data simply thrown in the trash, and then the camera's memory pointer reset before the camera is released. How, one might ask, did anyone produce something so primitive? Well, it is done. Perhaps the money saved thereby was at least in part devoted to producing better optics for the camera. At least, one can hope so. But people did produce those cameras, and people have bought them. But does anyone want to reproduce the code to support this kind of crap in the kernel? And go through all of the hoops required in order to fake the behavior which one woulld "expect" from a "real" still camera? It has already been done in camlibs/jl2005c and isn't that enough?
This actually is an example where doing a kernel driver would be easier, a kernel driver never exits. So it can simply remember where it was reading (and cache the data it has read sofar). If an app requests picture 10, we read 1-10, cache them and return picture 10 to the app, then the same or another app asks for picture 4, get it from cache, asks for picture 20 read 11-20, etc. Having written code for various small digital picture frames (the keychain models) I know where you are coming from. Trust me I do. Recently I had an interesting bug report, with a corrupt PAT (picture allocation table) turns out that when deleting a picture through the menu inside the frame a different marker gets written to the PAT then when deleting it with the windows software, Fun huh? So yeah duplicating this code is no fun, but it is the only realistic solution which will get us a 100% reliable and robust user experience. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
