On Tue, 9 Aug 2011, Hans de Goede wrote: > Hi, > > On 08/09/2011 07:10 PM, Theodore Kilgore wrote: > > > > > > On Tue, 9 Aug 2011, Hans de Goede wrote: > > <snip> > > > No, but both Adam and I realized, approximately at the same time > > yesterday afternoon, something which is rather important here. Gphoto is > > not developed exclusively for Linux. Furthermore, it has a significant > > user base both on Windows and on MacOS, not to mention BSD. It really > > isn't nice to be screwing around too much with the way it works. > > Right, so my plan is not to rip out the existing camlibs from libgphoto2, > but to instead add a new camlib which talks to /dev/video# nodes which > support the new to be defined v4l2 API for this. This camlib will then > take precedence over the old libusb based ones when running on a system > which has a new enough kernel. On systems without the new enough kernel > the matching portdriver won't find any ports, so the camlib will be > effectively disabled. And then, I assume you mean, the old camlib will still work. On BSD the port driver for this new /dev/video# > API and the camlib won't even get compiled. > > <snip> > > > > It is time to quit thinking in band-aides and solve this properly, > > > 1 logical device means it gets 1 driver. > > > > > > This may be an approach which means some more work then others, but > > > I believe in the end that doing it right is worth the effort. > > > > Clearly, we agree about "doing it right is worth the effort." The whole > > discussion right now is about what is "right." > > I'm sorry but I don't get the feeling that the discussion currently is > focusing on what is "right". You are very impatient. > To me too much attention is being spend > on not throwing away the effort put in the current libgphoto2 camlibs, > which I don't like for 2 reasons: > 1) It distracts from doing what is right > 2) It ignores the fact that a lot has been learned in doing those > camlibs, really really a lot. and all that can be re-used in a kernel > driver. Note that your two items can contradict or cancel each other out if one is not careful? > > Let me try to phrase it in a way I think you'll understand. If we > agree on doing it right over all other things (such as the fact > that doing it right may take a considerable effort). Then this > could be an interesting assignment for some of the computer science > students I used to be a lecturer for. This assignment could read > something like "Given the existing situation and knowledge < > describe all that here>, do a re-design for the driverstack > for these dual mode cameras, assuming a completely fresh start". > > Now if I were to give this assignment to a group of students, and > they would keep coming back with the "but re-doing the camlibs > in kernelspace is such a large effort, and we already have > them in userspace" argument against using one unified driver > for these devices, I would give them an F, because they are > clearly missing the "assuming a completely fresh start" > part of the assignment. Well, for one thing, Hans, we do not have here any instructor who is giving us an assignment. And nobody is in the position to specify that the assignment says "assuming a completely fresh start" -- unless Linus happens to be reading this thread and chimes in. Otherwise, unless there is a convincing demonstration that "assuming a completely fresh start" is an absolute and unavoidable necessity, someone is probably going to disagree. > > I'm sorry if this sounds a bit harsh, Yes, I am sorry about that, too. but this is the way how > the current discussion feels to me. If we agree on aiming for > "doing it right" then with that comes to me doing a software > design from scratch, so without taking into account what is > already there. Here, a counter-argument is to point out, as I did in a mail earlier this afternoon, that "without taking account what is already there" might possibly let one overlook something important. And, no, I am not referring to the userspace-kernelspace problem with this. I am referring to the fact that simply to dump the entire contents of the camera "into cache" (and to keep it there for quite a while) might not necessarily be a good idea and it had been quite consciously rejected to do that in the design of libgphoto2. Not because it is in userspace, but because to do that eats up and ties up RAM of which one cannot assume there is a surplus. Do not misunderstand, though. I am not even going so far as to say that libgphoto2 made the right decision. It certainly has its drawbacks, in that it places severe requirements on someone programming a driver for a really stupid camera. But what I *am* saying is that the issue was anticipated, the issue was faced, and a conscious decision was made. This is the opposite of not anticipating, not facing an issue, and not making any conscious decision. Oh, another example of such lack of deep thought has produced the current crisis, too. I am referring to the amazing decision of some user interface designers that an app for downloading still photos has to be fired up immediately, just as soon as the "still camera" is plugged in. I would really hate to be a passenger in a sailboat piloted by one of those guys. But, hey, nobody is perfect. > > There are of course limits to the from scratch part, in the > end we want this to slot into the existing Linux practices > for webcams and stillcams, which means: > 1) offering a v4l2 /dev/video# node for streaming; and > 2) access to the pictures stored on the camera through libgphoto > > Taking these 2 constrictions into account, and combining that > with my firm believe that the solution to all the device sharing > problems is handling both functions in a single driver, I end > up with only 1 option: > > Have a kernel driver which provides both functions of the device, > with the streaming exported as a standard v4l2 device, and the > stillcam function exported with some to be defined API. Combined > with a libgphoto2 portlib and camlib for this new API, so that > existing libgphoto2 apps can still access the pictures as if > nothing was changed. Well, what I _do_ think is that we need to agree about precisely what is supposed to work and what is not, in an operational sense. But we are still fuzzy about that. For example, you seemed to assert this morning that the webcam functionality needs to be able to preempt any running stillcam app and to grab the camera. Why? Or did I misunderstand you? Then after we (and everybody else with an interest in the matter) have settled on precisely how the outcome is supposed to behave, we need to take a couple of test cases. Probably the best would be to, get some people to look at one driver and see if anything can be done to make that driver work better, using either Plan A or Plan B, or, for that matter, Plan C. Theodore Kilgore -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
