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? And because of that, isn't that just a bug in their code that has to be fixed no matter what, and this driver-disconnect thing would not really affect the issue? Fixing userspace bugs with kernel driver changes seems a bit harsh :) 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
