On Thu, 4 Aug 2011, Mauro Carvalho Chehab wrote: > Em 04-08-2011 08:39, Hans de Goede escreveu: > > Hi, > > > > On 08/03/2011 10:36 PM, Mauro Carvalho Chehab wrote: > >> Em 03-08-2011 16:53, Theodore Kilgore escreveu: > > > > <snip snip> > > > >>> Mauro, > >>> > >>> Not saying that you need to change the program for this session to deal > >>> with this topic, but an old and vexing problem is dual-mode devices. It is > >>> an issue which needs some kind of unified approach, and, in my opinion, > >>> consensus about policy and methodology. > >>> > >>> As a very good example if this problem, several of the cameras that I have > >>> supported as GSPCA devices in their webcam modality are also still cameras > >>> and are supported, as still cameras, in Gphoto. This can cause a collision > >>> between driver software in userspace which functions with libusb, and on > >>> the other hand with a kernel driver which tries to grab the device. > >>> > >>> Recent attempts to deal with this problem involve the incorporation of > >>> code in libusb which disables a kernel module that has already grabbed the > >>> device, allowing the userspace driver to function. This has made life a > >>> little bit easier for some people, but not for everybody. For, the device > >>> needs to be re-plugged in order to re-activate the kernel support. But > >>> some of the "user-friencly" desktop setups used by some distros will > >>> automatically start up a dual-mode camera with a gphoto-based program, > >>> thereby making it impossible for the camera to be used as a webcam unless > >>> the user goes for a crash course in how to disable the "feature" which has > >>> been so thoughtfully (thoughtlessly?) provided. > >>> > >>> As the problem is not confined to cameras but also affects some other > >>> devices, such as DSL modems which have a partition on them and are thus > >>> seen as Mass Storage devices, perhaps it is time to try to find a > >>> systematic approach to problems like this. > >>> > >>> There are of course several possible approaches. > >>> > >>> 1. A kernel module should handle everything related to connecting up the > >>> hardware. In that case, the existing userspace driver has to be modified > >>> to use the kernel module instead of libusb. Those who support this option > >>> would say that it gets everything under the control of the kernel, where > >>> it belongs. OTOG, the possible result is to create a minor mess in > >>> projects like Gphoto. > >>> > >>> 2. The kernel module should be abolished, and all of its functionality > >>> moved to userspace. This would of course involve difficulties > >>> approximately equivalent to item 1. An advantage, in the eyes of some, > >>> would be to cut down on the > >>> yet-another-driver-for-yet-another-piece-of-peculiar-hardware syndrome > >>> which obviously contributes to an in principle unlimited increase in the > >>> size of the kernel codebase. A disadvantage would be that it would create > >>> some disruption in webcam support. > >>> > >>> 3. A further modification to libusb reactivates the kernel module > >>> automatically, as soon as the userspace app which wanted to access the > >>> device through a libusb-based driver library is closed. This seems > >>> attractive, but it has certain deficiencies as well. One of them is that > >>> it can not necessarily provide a smooth and informative user experience, > >>> since circumstances can occur in which something appears to go wrong, but > >>> the user gets no clear message saying what the problem is. In other words, > >>> it is a patchwork solution which only slightly refines the current > >>> patchwork solution in libusb, which is in itself only a slight improvement > >>> on the original, unaddressed problem. > >>> > >>> 4. ??? > >>> > >>> Several people are interested in this problem, but not much progress has > >>> been made at this time. I think that the topic ought to be put somehow on > >>> the front burner so that lots of people will try to think of the best way > >>> to handle it. Many eyes, and all that. > >>> > >>> Not saying change your schedule, as I said. Have a nice conference. I wish > >>> I could attend. But I do hope by this message to raise some general > >>> concern about this problem. > >> > >> That's an interesting issue. > >> > >> A solution like (3) is a little bit out of scope, as it is a pure userspace > >> (or a mixed userspace USB stack) solution. > >> > >> Technically speaking, letting the same device being handled by either an > >> userspace or a kernelspace driver doesn't seem smart to me, due to: > >> - Duplicated efforts to maintain both drivers; > >> - It is hard to sync a kernel driver with an userspace driver, > >> as you've pointed. > >> > >> So, we're between (1) or (2). > >> > >> Moving the solution entirely to userspace will have, additionally, the > >> problem of having two applications trying to access the same hardware > >> using two different userspace instances (for example, an incoming videoconf > >> call while Gphoto is opened, assuming that such videoconf call would also > >> have an userspace driver). > >> > >> IMO, the right solution is to work on a proper snapshot mode, in kernelspace, > >> and moving the drivers that have already a kernelspace out of Gphoto. > >> > > > > I agree that solution 1) so all the driver bits in kernelspace is the right > > solution. This is unrelated to snapshot mode though, snapshot mode is all > > about taking live snapshots. Where as in this case we are downloading > > pictures which have already been taken (perhaps days ago) from device memory. > > > > What we need for this is a simple API (new v4l ioctl's I guess) for the > > stillcam mode of these dual mode cameras (stillcam + webcam). So that the > > webcam drivers can grow code to also allow access to the stored pictures, > > which were taken in standalone (iow not connected to usb) stillcam mode. > > > > This API does not need to be terribly complex. AFAIK all of the currently > > supported dual cam cameras don't have filenames only picture numbers, Trying to remember any actual exceptions to this statement. No, at the moment I can not. But better not to assume it could never happen. > > so the API could consist of a simple, get highest picture nr, is picture > > X present (some slots may contain deleted pictures), get picture X, > > delete picture X, delete all API. One needs to be really careful about setting up a general framework for that kind of thing. Some of these cameras can do truly amazing things, which I mean in a negative sense, not a positive sense. The sq905 cameras are an extreme example. The only way to select a photo to download is to download all previous photos and toss the data. The jl2005c cameras (which mercifully are not dual-mode cameras) are even worse. Those will only permit one to dump the entire memory of the camera. What I am saying is that weird behavior of cameras designed with insane chipsets built with cost-cutting as the first priority must be anticipated. > > That sounds to work. I would map it on a way close to the controls API > (or like the DVB FE_[GET|SET]_PROPERTY API), as this would make easier > to expand it in the future, if we start to see webcams with file names > or other things like that. > > > > > If others are willing to help flesh out an API for this, I can write > > a proposal and submit it a few weeks before the Media Subsystem Workshop > > starts. 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
