On Tue, Jan 12, 2010 at 05:28:04PM +0100, Hans de Goede wrote: > Hi, > > On 01/12/2010 06:25 PM, Greg KH wrote: >> On Tue, Jan 12, 2010 at 05:36:09PM +0100, Hans de Goede wrote: >>> Hi, >>> >>> Sorry not coded yet, I first wanted to discuss the >>> principle. >>> >>> I'm working on supporting so called dual mode cameras, which >>> are cheap still cameras (low res, fixed lens, photos stored in >>> battery backed sram), which can double as webcams. >>> >>> We currently have webcam drivers in the v4l subsystem for quite a >>> few of these, but the coordination with libgphoto, which handles >>> the still cam function from userspace is less then ideal. >>> >>> One of the problems is that if gphoto tries to access the device >>> while another app is streaming from the webcam, this is allowed >>> and the webcam driver sees a usb disconnect, after which the webcam >>> app often is left in a very confused state. >>> >>> So I would like to be able to tell from the driver to return >>> -EBUSY to the USBDEVFS_DISCONNECT ioctl. >>> >>> The idea here is for the driver to temporary disable USBDEVFS_DISCONNECT, >>> when the application starts the video stream (not on opening >>> the device as some apps like control panels for webcams will keep the >>> device open indefinitely). And re-allow it when the cam stops streaming. >>> >>> Does this sound something for which a patch to allow driver to >>> temporary disable USBDEVFS_DISCONNECT would be acceptable ? >> >> I don't know, I think that if a user wants to disconnect a driver from a >> device, and has the proper permission to do so, they should be able to. >> >> What is the main problem with the other userspace program that has it >> confused if the device goes away? Isn't that the same problem they >> would have if the device was physically disconnected from the machine? >> > > Well, all the userspace program will get from this point on is -EIO, > at which point it can either retry (which will fail again), or abort. > Either way the end user experience is not good. Why would they not get a -ENODEV, like as if when the device is removed from the system, as the code path in the video usb driver is the same, right? > Normally when a device is single use only, and an app has it open, when > an other app wants to open it it will get -EBUSY. Sure. > The mix of userspace / kernelspace drivers in this case breaks this > behavior as any libgphoto2 using app can now steal the device from > the webcam using app. But you gave that app the permission to do that. And you ran the program that asked to do that. So why would we want to forbid that from happening? >> Fixing userspace bugs with kernel driver changes seems a bit harsh :) > > Oh I completely agree, and I also agree that apps which looses their > /dev/video device because of unplug should handle that properly, still > the stealing of the device from the webcam app by libgphoto apps is > unwanted behavior in my book, and that is what I'm trying to fix. Then fix libgphoto please. I don't see a kernel issue here yet. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
