Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 05:43:06PM -0500, Theodore Kilgore wrote: there's nothing in the USB spec that says you need different product IDs for different modes of operation. No matter if it's still or webcam configuration, the underlying function is the same: capture images using a set of lenses and image sensor. True, true. But I will add that most of these cameras are Class 255, Subclass 255, Protocol 255 (Proprietary, Proprietary, Proprietary). well, if the manufacturer doesn't want to implement UVC for whatever reason, it's his call ;-) -- balbi signature.asc Description: Digital signature
Re: Improving kernel - userspace (usbfs) usb device hand off
Em 13-06-2011 06:05, Felipe Balbi escreveu: Hi, On Fri, Jun 10, 2011 at 05:43:06PM -0500, Theodore Kilgore wrote: there's nothing in the USB spec that says you need different product IDs for different modes of operation. No matter if it's still or webcam configuration, the underlying function is the same: capture images using a set of lenses and image sensor. True, true. But I will add that most of these cameras are Class 255, Subclass 255, Protocol 255 (Proprietary, Proprietary, Proprietary). well, if the manufacturer doesn't want to implement UVC for whatever reason, it's his call ;-) This argument is bogus. UVC were implemented too late. There are lots of chipsets that are not UVC-compliant, simply because there were no UVC at the time those chipsets were designed. Still today, newer devices using those chipsets are still at the market. This is the same as saying that we should not support USB 1.1 or USB 2.0 because they're not fully USB 3.0 compliant. Mauro. -- 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
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On 06/11/2011 06:19 PM, Theodore Kilgore wrote: On Sat, 11 Jun 2011, Hans de Goede wrote: Hi, Given the many comments in this thread, I'm just going reply to this one, and try to also answer any other ones in this mail. As far as the dual mode camera is involved, I agree that that should be fixed in the existing v4l2 drivers + libgphoto. I think that Felipe's solution to also handle the stillcam part in kernel space for dual mode cameras (and add a libgphoto cam driver which knows how to talk the new kernel API for this), is the best solution. Unfortunately this will involve quite a bit of work, but so be it. Hans, It appears to me that the solution ought to be at hand, actually. I was not aware of the recent changes in libusb, which I understand are supposed to allow a kernel driver to be hooked up again. To review the situation: 1. As of approximately 2 years ago, libusb already was so configured as to suspend the kernel module for a dual-mode device if a userspace-based program tried to claim the device. 2. At this point with the more recent versions of libusb (see the last message from yesterday, from Xiaofan Chen), we are supposed to be able to re-activate the kernel module for the device when it is relinquished by userspace. This ought to take care of the problems completely, provided that the new capabilities of libusb are actually used and called upon in libgphoto2. I have checked on what is happening, just now, on my own machine. I have libusb version 1.08 which ought to be recent enough. The advertised abilities did not work, however. Presumably, what is missing is on the other end of the problem, most likely in the functions in libgphoto2 which hook up a camera. That code would presumably need to call upon the new functionality of libusb. My currently installed version of libgphoto2 (from svn, but several months old) clearly does not contain the needed functionality. But it might have been put in recently and I did not notice. I guess that the first thing to do is to update my gphoto tree and then to see what happens. If things still don't work, then something needs to be updated and then things ought to work. I will try to see that something gets done about this. Thank you for raising the old issue of dual-mode devices yet again, and thanks to Xiaofan Chen for pointing out that the needed missing half of the functionality is supposed to exist now in libusb. That had escaped my attention. Actually libusb and libgphoto have been using the rebind orginal driver functionality of the code for quite a while now, unfortunately this does not solve the problem, unless we somehow move to 1 central coordinator for the device the user experience will stay subpar. Example, user downloads pictures from the camera using shotwell, gthumb, fspot or whatever, keeps the app in question open and the app in question keeps the gphoto2 device handle open. User wants to do some skyping with video chat, skype complains it cannot find the device, since the kernel driver currently is unbound. - Poor user experience. With having both functions in the kernel, the kernel could actually allow skype to use the dual mode cameras as video source, and if the user then were to switch to f-spot and try to import more photo's then he will get an -ebusy in f-spot. If he finishes skyping and then returns to f-spot everything will just continue working. This is the kind of seamless user experience I'm aiming for here. 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
Re: Improving kernel - userspace (usbfs) usb device hand off
On Sun, 12 Jun 2011, Hans de Goede wrote: Hi, On 06/11/2011 06:19 PM, Theodore Kilgore wrote: On Sat, 11 Jun 2011, Hans de Goede wrote: Hi, Given the many comments in this thread, I'm just going reply to this one, and try to also answer any other ones in this mail. As far as the dual mode camera is involved, I agree that that should be fixed in the existing v4l2 drivers + libgphoto. I think that Felipe's solution to also handle the stillcam part in kernel space for dual mode cameras (and add a libgphoto cam driver which knows how to talk the new kernel API for this), is the best solution. Unfortunately this will involve quite a bit of work, but so be it. Hans, It appears to me that the solution ought to be at hand, actually. I was not aware of the recent changes in libusb, which I understand are supposed to allow a kernel driver to be hooked up again. To review the situation: 1. As of approximately 2 years ago, libusb already was so configured as to suspend the kernel module for a dual-mode device if a userspace-based program tried to claim the device. 2. At this point with the more recent versions of libusb (see the last message from yesterday, from Xiaofan Chen), we are supposed to be able to re-activate the kernel module for the device when it is relinquished by userspace. This ought to take care of the problems completely, provided that the new capabilities of libusb are actually used and called upon in libgphoto2. I have checked on what is happening, just now, on my own machine. I have libusb version 1.08 which ought to be recent enough. The advertised abilities did not work, however. Presumably, what is missing is on the other end of the problem, most likely in the functions in libgphoto2 which hook up a camera. That code would presumably need to call upon the new functionality of libusb. My currently installed version of libgphoto2 (from svn, but several months old) clearly does not contain the needed functionality. But it might have been put in recently and I did not notice. I guess that the first thing to do is to update my gphoto tree and then to see what happens. If things still don't work, then something needs to be updated and then things ought to work. I will try to see that something gets done about this. Thank you for raising the old issue of dual-mode devices yet again, and thanks to Xiaofan Chen for pointing out that the needed missing half of the functionality is supposed to exist now in libusb. That had escaped my attention. Actually libusb and libgphoto have been using the rebind orginal driver functionality of the code for quite a while now, Oh? I can see that libusb is doing that, and I can also see that there is a public function for _unbinding_ a kernel driver, namely int usb_detach_kernel_driver_np() found in usb.h and it is used in libgphoto, as well. I am not sure that there is any corresponding rebind function which is public. Is it perhaps int usb_get_driver_np() ??? By context (looking at libgphoto2-port/usb/libusb.c) I would think that this function is not the rebind function, but is only checking whether or not there is any potential conflict with a kernel driver. If I am right, then where is the publicly exported rebind function, and where does it currently get used in libgphoto2? So frankly after my eagerness yesterday I do not see how it can easily be made to work, after all. unfortunately this does not solve the problem, unless we somehow move to 1 central coordinator for the device the user experience will stay subpar. Example, user downloads pictures from the camera using shotwell, gthumb, fspot or whatever, keeps the app in question open and the app in question keeps the gphoto2 device handle open. User wants to do some skyping with video chat, skype complains it cannot find the device, since the kernel driver currently is unbound. - Poor user experience. Poor user experience, or merely poor user? The user ought to know better. Of course, I do agree that there are lots of such people, and it is a good idea to try to put up warning signs. With having both functions in the kernel, the kernel could actually allow skype to use the dual mode cameras as video source, and if the user then were to switch to f-spot and try to import more photo's then he will get an -ebusy in f-spot. If he finishes skyping and then returns to f-spot everything will just continue working. This is the kind of seamless user experience I'm aiming for here. Regards, Hans Yes, I can see where you are coming from. But if the camera really will not let you run skype and fspot at the same time, which I do not believe it would allow on _any_ operating system, then each app should give an error message which says it cannot be run unless and until the other app has been closed. If that has to
Re: Improving kernel - userspace (usbfs) usb device hand off
On Mon, Jun 13, 2011 at 5:20 AM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: On Sun, 12 Jun 2011, Hans de Goede wrote: Actually libusb and libgphoto have been using the rebind orginal driver functionality of the code for quite a while now, Oh? I can see that libusb is doing that, and I can also see that there is a public function for _unbinding_ a kernel driver, namely int usb_detach_kernel_driver_np() found in usb.h and it is used in libgphoto, as well. I am not sure that there is any corresponding rebind function which is public. Is it perhaps int usb_get_driver_np() ??? By context (looking at libgphoto2-port/usb/libusb.c) I would think that this function is not the rebind function, but is only checking whether or not there is any potential conflict with a kernel driver. If I am right, then where is the publicly exported rebind function, and where does it currently get used in libgphoto2? http://gphoto.svn.sourceforge.net/viewvc/gphoto/trunk/libgphoto2/libgphoto2_port/usb/libusb.c?revision=13652view=markup The rebind happened under the function static int gp_port_usb_close (GPPort *port). Since libgphoto2 is still using libusb-0.1, the unbind is using usbfs IOCTL directly (USBDEVFS_CONNECT). So frankly after my eagerness yesterday I do not see how it can easily be made to work, after all. unfortunately this does not solve the problem, unless we somehow move to 1 central coordinator for the device the user experience will stay subpar. Now I understand what Hans is saying. It will be a lot of work trying to sort out this issue in userspace. What can be the single central coordinator? A device manager applet listing the program or service which hold the device? Example, user downloads pictures from the camera using shotwell, gthumb, fspot or whatever, keeps the app in question open and the app in question keeps the gphoto2 device handle open. User wants to do some skyping with video chat, skype complains it cannot find the device, since the kernel driver currently is unbound. - Poor user experience. Poor user experience, or merely poor user? The user ought to know better. Of course, I do agree that there are lots of such people, and it is a good idea to try to put up warning signs. It is difficult to call the users poor users in this case. Since they may not know that the other open program is holding the device. Some warning message may help, not I can not find the device though. It would be better to pinpoint which program is holding the device and then ask the user to close that program. I understand this is easily said than done... Similar experiences for Windows about the serial port, sometimes it is difficult for the user to know that some program or service are holding the serial port so that the other program or will fail or Windows complain that it is still open when you want to undock the computer. With having both functions in the kernel, the kernel could actually allow skype to use the dual mode cameras as video source, and if the user then were to switch to f-spot and try to import more photo's then he will get an -ebusy in f-spot. If he finishes skyping and then returns to f-spot everything will just continue working. This is the kind of seamless user experience I'm aiming for here. Yes, I can see where you are coming from. But if the camera really will not let you run skype and fspot at the same time, which I do not believe it would allow on _any_ operating system, then each app should give an error message which says it cannot be run unless and until the other app has been closed. If that has to happen at the kernel level, then OK. Yes. From what I read, to solve it in kernel or to solve it in user space are both a lot of work. Personally I tend to think to solve it in user space is more feasible. -- Xiaofan -- 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
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, Given the many comments in this thread, I'm just going reply to this one, and try to also answer any other ones in this mail. As far as the dual mode camera is involved, I agree that that should be fixed in the existing v4l2 drivers + libgphoto. I think that Felipe's solution to also handle the stillcam part in kernel space for dual mode cameras (and add a libgphoto cam driver which knows how to talk the new kernel API for this), is the best solution. Unfortunately this will involve quite a bit of work, but so be it. On 06/10/2011 04:48 PM, Alan Stern wrote: On Fri, 10 Jun 2011, Hans de Goede wrote: Hi all, The current API for managing kernel - userspace is a bit rough around the edges, so I would like to discuss extending the API. First of all an example use case scenarios where the current API falls short. 1) Redirection of USB devices to a virtual machine, qemu, vbox, etc. all have the ability to redirect a USB device to the virtual machine, and they all use usbfs for this. The first thing which will happen here when the user selects a device to redirect is a IOCTL_USBFS_DISCONNECT. This causes the kernel driver to see a device unplug, with no chances for the kernel driver to do anything against this. Now lets say the user does the following: -write a file to a usb flash disk -redirect the flash disk to a vm Currently this will cause the usb mass storage driver to see a disconnect, and any possible still pending writes are lost ... This is IMHO unacceptable, but currently there is nothing we can do to avoid this. You haven't given a proper description of the problem. See below. I think I've given an excellent description of the problem, drivers can be unbound from devices, and there is no way for drivers to block this. All I'm asking for is for a new usbfs try_disconnect ioctl which the currently bound driver has a chance blocking nothing more nothing less. snip dual mode camera stuff So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem Not feasible. usb-storage has no idea whether or not a device it controls has a mounted filesystem. (All it does is send SCSI commands to a device and get back the results.) Since that's the main use case you're interested in, this part of the proposal seems destined to fail. This is not completely true, I cannot rmmod usb-storage as long as disks using it are mounted. I know this is done through the global module usage count, so this is not per usb-storage device. But extending the ref counting to be per usb-storage device should not be hard. All the accounting is already done for this. But userspace _does_ know where the mounted filesystems are. Therefore userspace should be responsible for avoiding programs that want to take control of devices holding these filesystems. That's the reason why usbfs device nodes are owned by root and have 0644 mode; there're can be written to only by programs with superuser privileges -- and such programs are supposed to be careful about what they do. Yes, and what I'm asking for is for an easy way for these programs to be careful. A way for them to ask the kernel, which in general is responsible for things like this and traditionally does resource management and things which come with that like refcounting: unbind the driver from this device unless the device is currently in use. Why can't this be done in userspace, simply put: 1) Process a checks if the usb-storage device is not used 2) Process b mounts it after the check 3) Process a unbinds the driver Yes this can be avoided if all binding/unbinding and all mounting happens under control of a single instance. However this requires completely re-inventing userspace... Also note that the notion of this can be extended to other devices, want to ubs-redirect a usb printer to a vm better not do it halfway through a printjob being spooled. Want to usb-redirect a usb webcam to a vm, better not do it while something is streaming video from the webcam, etc. etc. And please don't come with the inevitable if it hurts do not do that argument. We want to provide this kind of functionality to non tech savy computer users, and things should just work, including telling the user that the device is currently in use rather then wrecking his printjob or filesystem. 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
Re: Improving kernel - userspace (usbfs) usb device hand off
On Sat, 11 Jun 2011, Hans de Goede wrote: Hi, Given the many comments in this thread, I'm just going reply to this one, and try to also answer any other ones in this mail. As far as the dual mode camera is involved, I agree that that should be fixed in the existing v4l2 drivers + libgphoto. I think that Felipe's solution to also handle the stillcam part in kernel space for dual mode cameras (and add a libgphoto cam driver which knows how to talk the new kernel API for this), is the best solution. Unfortunately this will involve quite a bit of work, but so be it. Hans, It appears to me that the solution ought to be at hand, actually. I was not aware of the recent changes in libusb, which I understand are supposed to allow a kernel driver to be hooked up again. To review the situation: 1. As of approximately 2 years ago, libusb already was so configured as to suspend the kernel module for a dual-mode device if a userspace-based program tried to claim the device. 2. At this point with the more recent versions of libusb (see the last message from yesterday, from Xiaofan Chen), we are supposed to be able to re-activate the kernel module for the device when it is relinquished by userspace. This ought to take care of the problems completely, provided that the new capabilities of libusb are actually used and called upon in libgphoto2. I have checked on what is happening, just now, on my own machine. I have libusb version 1.08 which ought to be recent enough. The advertised abilities did not work, however. Presumably, what is missing is on the other end of the problem, most likely in the functions in libgphoto2 which hook up a camera. That code would presumably need to call upon the new functionality of libusb. My currently installed version of libgphoto2 (from svn, but several months old) clearly does not contain the needed functionality. But it might have been put in recently and I did not notice. I guess that the first thing to do is to update my gphoto tree and then to see what happens. If things still don't work, then something needs to be updated and then things ought to work. I will try to see that something gets done about this. Thank you for raising the old issue of dual-mode devices yet again, and thanks to Xiaofan Chen for pointing out that the needed missing half of the functionality is supposed to exist now in libusb. That had escaped my attention. Theodore Kilgore -- 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
Re: Improving kernel - userspace (usbfs) usb device hand off
On Sat, 11 Jun 2011, Hans de Goede wrote: So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem Not feasible. usb-storage has no idea whether or not a device it controls has a mounted filesystem. (All it does is send SCSI commands to a device and get back the results.) Since that's the main use case you're interested in, this part of the proposal seems destined to fail. This is not completely true, I cannot rmmod usb-storage as long as disks using it are mounted. I know this is done through the global module usage count, so this is not per usb-storage device. But extending the ref counting to be per usb-storage device should not be hard. All the accounting is already done for this. It would be harder than you think. All the accounting is _not_ already being done. What you're talking about would amount to a significant change in the driver model core and the SCSI core. It isn't just a USB thing. But userspace _does_ know where the mounted filesystems are. Therefore userspace should be responsible for avoiding programs that want to take control of devices holding these filesystems. That's the reason why usbfs device nodes are owned by root and have 0644 mode; there're can be written to only by programs with superuser privileges -- and such programs are supposed to be careful about what they do. Yes, and what I'm asking for is for an easy way for these programs to be careful. A way for them to ask the kernel, which in general is responsible for things like this and traditionally does resource management and things which come with that like refcounting: unbind the driver from this device unless the device is currently in use. Sure. At the moment the kernel does not keep track of whether a device is currently in use -- at least, not in the way you mean. I'm not saying this can't be done. But it would be a bigger job than you think, and this isn't the appropriate thread to discuss it. Alan Stern -- 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
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote: Currently this will cause the usb mass storage driver to see a disconnect, and any possible still pending writes are lost ... This is IMHO unacceptable, but currently there is nothing we can do to avoid this. 2) So called dual mode cameras are (cheap) stillcams often even without an lcdscreen viewfinder, and battery backed sram instead of flash, which double as a webcam. We have drivers for both the stillcam function of these (in libgphoto2, so using usbfs) as well as for the webcam function (v4l2 kernel drivers). These drivers work well, and are mature. Yet the user experience is rather poor. Under gnome the still-cam contents will be automatically be made available as a drive using a gvfs-gphoto2 fuse mount. This however involves sending a disconnect to the v4l2 kernel driver, and thus the /dev/video# node disappearing. So if a user wants to use the device as a webcam he/she needs to first go to nautilus and unmount the gvfs mount. Until that is done the user will simply get a message from an app like cheese that he has no webcam, not even an ebusy error, just that he has no such device. that sounds quite weird. Should only happen if still image and video functions are on different configurations or different alt-settings of the same interface. But if they are on same configurations and separate interfaces, you should be able to bind gphoto to the still image interface and v4l2 to the camera interface. How's the device setup ? So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem I'm not sure you even need a driver callback for that. Should we leave that to Desktop manager ? -- balbi signature.asc Description: Digital signature
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On 06/10/2011 10:22 AM, Felipe Balbi wrote: Hi, On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote: Currently this will cause the usb mass storage driver to see a disconnect, and any possible still pending writes are lost ... This is IMHO unacceptable, but currently there is nothing we can do to avoid this. 2) So called dual mode cameras are (cheap) stillcams often even without an lcdscreen viewfinder, and battery backed sram instead of flash, which double as a webcam. We have drivers for both the stillcam function of these (in libgphoto2, so using usbfs) as well as for the webcam function (v4l2 kernel drivers). These drivers work well, and are mature. Yet the user experience is rather poor. Under gnome the still-cam contents will be automatically be made available as a drive using a gvfs-gphoto2 fuse mount. This however involves sending a disconnect to the v4l2 kernel driver, and thus the /dev/video# node disappearing. So if a user wants to use the device as a webcam he/she needs to first go to nautilus and unmount the gvfs mount. Until that is done the user will simply get a message from an app like cheese that he has no webcam, not even an ebusy error, just that he has no such device. that sounds quite weird. Should only happen if still image and video functions are on different configurations or different alt-settings of the same interface. But if they are on same configurations and separate interfaces, you should be able to bind gphoto to the still image interface and v4l2 to the camera interface. How's the device setup ? These are very cheap devices, and as such poorly designed. There still and webcam functionality is on the same interface. This is likely done this way because the devices cannot handle both functions at the same time. So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem I'm not sure you even need a driver callback for that. Should we leave that to Desktop manager ? Not sure what you mean here, but we need for a way for drivers to say no to a software caused disconnection. See my usb mass storage device which is still mounted getting redirected to a vm example. This cannot be reliably done from userspace. Where as it is trivial to do this from kernel space. One could advocate to make the existing disconnect ioctl use the new soft_disconnect usb_driver callback instead of adding a new usbfs ioctl for this, but that means that a driver can block any and all userspace triggered disconnects. Where as having a new ioctl, means that apps which want to play nice can play nice, while keeping the possibility of a hard userspace initiated disconnect. One could also argue that making the existing disconnect ioctl return -EBUSY in some cases now is an ABI change. 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
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 10:36:47AM +0200, Hans de Goede wrote: On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote: Currently this will cause the usb mass storage driver to see a disconnect, and any possible still pending writes are lost ... This is IMHO unacceptable, but currently there is nothing we can do to avoid this. 2) So called dual mode cameras are (cheap) stillcams often even without an lcdscreen viewfinder, and battery backed sram instead of flash, which double as a webcam. We have drivers for both the stillcam function of these (in libgphoto2, so using usbfs) as well as for the webcam function (v4l2 kernel drivers). These drivers work well, and are mature. Yet the user experience is rather poor. Under gnome the still-cam contents will be automatically be made available as a drive using a gvfs-gphoto2 fuse mount. This however involves sending a disconnect to the v4l2 kernel driver, and thus the /dev/video# node disappearing. So if a user wants to use the device as a webcam he/she needs to first go to nautilus and unmount the gvfs mount. Until that is done the user will simply get a message from an app like cheese that he has no webcam, not even an ebusy error, just that he has no such device. that sounds quite weird. Should only happen if still image and video functions are on different configurations or different alt-settings of the same interface. But if they are on same configurations and separate interfaces, you should be able to bind gphoto to the still image interface and v4l2 to the camera interface. How's the device setup ? These are very cheap devices, and as such poorly designed. There still and webcam functionality is on the same interface. This is likely done this way because the devices cannot handle both functions at the same time. ok got it. So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem I'm not sure you even need a driver callback for that. Should we leave that to Desktop manager ? Not sure what you mean here, but we need for a way for drivers to say no to a software caused disconnection. See my usb mass storage device which is still mounted getting redirected to a vm example. This cannot in that case, why don't you just flush all data and continue ? Also, desktop manager knows that a particular device mounted, so it could also ask the user if s/he wants to continue. I'm not sure preventing a disconnect is a good thing. be reliably done from userspace. Where as it is trivial to do this from kernel space. One could advocate to make the existing disconnect ioctl use the new soft_disconnect usb_driver callback instead of adding a new usbfs ioctl for this, but that means that a driver can block any and all userspace triggered disconnects. Where as having a new ioctl, means that apps which want to play nice can play nice, while keeping the possibility of a hard userspace initiated disconnect. One could also argue that making the existing disconnect ioctl return -EBUSY in some cases now is an ABI change. OTOH, if the user really wants to move the usb device to the guest OS, he has just requested for that, so should we prevent it ? what we need is for the applications to be notified to exit cleanly and release the device because the user has requested to do so. No ? -- balbi signature.asc Description: Digital signature
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On 06/10/2011 10:42 AM, Felipe Balbi wrote: Hi, On Fri, Jun 10, 2011 at 10:36:47AM +0200, Hans de Goede wrote: On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote: snip So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem I'm not sure you even need a driver callback for that. Should we leave that to Desktop manager ? Not sure what you mean here, but we need for a way for drivers to say no to a software caused disconnection. See my usb mass storage device which is still mounted getting redirected to a vm example. This cannot in that case, why don't you just flush all data and continue ? Also, desktop manager knows that a particular device mounted, so it could also ask the user if s/he wants to continue. I'm not sure preventing a disconnect is a good thing. I assume you are sure preventing data loss is a good thing? Because in this example the 2 are the same. Also note I'm not suggestion at always preventing the disconnect, I'm suggesting to add a new try_disconnect ioctl, which apps which want to behave nicely can use instead of the regular disconnect ioctl, and then drivers can prevent the disconnect. Apps using the old ioctl will still get an unconditional disconnect as before. be reliably done from userspace. Where as it is trivial to do this from kernel space. One could advocate to make the existing disconnect ioctl use the new soft_disconnect usb_driver callback instead of adding a new usbfs ioctl for this, but that means that a driver can block any and all userspace triggered disconnects. Where as having a new ioctl, means that apps which want to play nice can play nice, while keeping the possibility of a hard userspace initiated disconnect. One could also argue that making the existing disconnect ioctl return -EBUSY in some cases now is an ABI change. OTOH, if the user really wants to move the usb device to the guest OS, he has just requested for that, so should we prevent it ? what we need is for the applications to be notified to exit cleanly and release the device because the user has requested to do so. No ? We are talking about a device with a mounted file system on it here, any process could be holding files open on there, and there currently exists no mechanism to notify all apps to exit cleanly and release the files. Even if there were some method for a desktop environment like gnome to ask apps to release those files, and all gnome apps where to be modified to support that mechanism, then there are still 1000-s of non gnome (or kde, xfce, whatever) apps which will not support that. We already have a mechanism to cleanly close down a filesystem, it is called unmount. And it will fail if apps have files open. All I'm suggesting is forwarding this ebusy failure to the application trying to disconnect the driver from the usb mass storage interface. Simply removing the filesystem from under apps holding files open will lead to io errors, and very unhappy apps. 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
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 02:19:20PM +0200, Hans de Goede wrote: So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem I'm not sure you even need a driver callback for that. Should we leave that to Desktop manager ? Not sure what you mean here, but we need for a way for drivers to say no to a software caused disconnection. See my usb mass storage device which is still mounted getting redirected to a vm example. This cannot in that case, why don't you just flush all data and continue ? Also, desktop manager knows that a particular device mounted, so it could also ask the user if s/he wants to continue. I'm not sure preventing a disconnect is a good thing. I assume you are sure preventing data loss is a good thing? Because in this example the 2 are the same. Also note I'm not suggestion at always preventing the disconnect, I'm suggesting to add a new try_disconnect ioctl, which apps which want to behave nicely can use instead of the regular disconnect ioctl, and then drivers can prevent the disconnect. Apps using the old ioctl will still get an unconditional disconnect as before. I'm just not sure if this should sit in the kernel. You can easily have some sort of device manager (much like udisks for storage) to track this down for ya. So instead of calling usbfs straight, you need to go via the device manager. This device manager should know that before calling 'disconnect' it must be sure there's nothing pending. One could also argue that making the existing disconnect ioctl return -EBUSY in some cases now is an ABI change. OTOH, if the user really wants to move the usb device to the guest OS, he has just requested for that, so should we prevent it ? what we need is for the applications to be notified to exit cleanly and release the device because the user has requested to do so. No ? We are talking about a device with a mounted file system on it here, any process could be holding files open on there, and there currently exists no mechanism to notify all apps to exit cleanly and release the files. Even if there were some method for a desktop environment like gnome to ask apps to release those files, and all gnome apps where to be modified to support that mechanism, then there are still 1000-s of non gnome (or kde, xfce, whatever) apps which will not support that. Still, I'm not sure this is argument good enough to add another sort of conflicting ioctl to the kernel. It won't prevent apps from calling the other disconnect anyway. And besides, if an app can be modified to use the try_disconnect ioctl, they can be modified for the system notification (on userland) too, can't they ? We already have a mechanism to cleanly close down a filesystem, it is called unmount. And it will fail if apps have files open. All I'm suggesting is forwarding this ebusy failure to the application trying to disconnect the driver from the usb mass storage interface. Simply removing the filesystem from under apps holding files open will lead to io errors, and very unhappy apps. Correct, but does the solution _have_ to sit in kernel ? I'm not sure. If you add the try_disconnect ioctl and all applications one your desktop, except one, are playing nice, you will still have problems. To me, it sounds much nicer to add such things on userland alone, in a way such that it doesn't matter if it's a usb storage, mmc card, or eSATA drive. That should be hidden from apps IMHO. -- balbi signature.asc Description: Digital signature
Re: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Hans de Goede wrote: Hi all, The current API for managing kernel - userspace is a bit rough around the edges, so I would like to discuss extending the API. First of all an example use case scenarios where the current API falls short. 1) Redirection of USB devices to a virtual machine, qemu, vbox, etc. all have the ability to redirect a USB device to the virtual machine, and they all use usbfs for this. The first thing which will happen here when the user selects a device to redirect is a IOCTL_USBFS_DISCONNECT. This causes the kernel driver to see a device unplug, with no chances for the kernel driver to do anything against this. Now lets say the user does the following: -write a file to a usb flash disk -redirect the flash disk to a vm Currently this will cause the usb mass storage driver to see a disconnect, and any possible still pending writes are lost ... This is IMHO unacceptable, but currently there is nothing we can do to avoid this. You haven't given a proper description of the problem. See below. 2) So called dual mode cameras are (cheap) stillcams often even without an lcdscreen viewfinder, and battery backed sram instead of flash, which double as a webcam. We have drivers for both the stillcam function of these (in libgphoto2, so using usbfs) as well as for the webcam function (v4l2 kernel drivers). These drivers work well, and are mature. Yet the user experience is rather poor. Under gnome the still-cam contents will be automatically be made available as a drive using a gvfs-gphoto2 fuse mount. This however involves sending a disconnect to the v4l2 kernel driver, and thus the /dev/video# node disappearing. So if a user wants to use the device as a webcam he/she needs to first go to nautilus and unmount the gvfs mount. Until that is done the user will simply get a message from an app like cheese that he has no webcam, not even an ebusy error, just that he has no such device. Again not good. As Felipe has mentioned, this sounds like the sort of problem that can better be solved in userspace. A dual-mode device like the one you describe really is either a still-cam or a webcam, never both at the same time. Hence what users need is a utility program to switch modes (by loading/unloading the appropriate programs or drivers). Or maybe a desktop daemon that could accomplish the same result automatically, based on requests from user programs. ### So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem Not feasible. usb-storage has no idea whether or not a device it controls has a mounted filesystem. (All it does is send SCSI commands to a device and get back the results.) Since that's the main use case you're interested in, this part of the proposal seems destined to fail. But userspace _does_ know where the mounted filesystems are. Therefore userspace should be responsible for avoiding programs that want to take control of devices holding these filesystems. That's the reason why usbfs device nodes are owned by root and have 0644 mode; there're can be written to only by programs with superuser privileges -- and such programs are supposed to be careful about what they do. b) It will allow for example a v4l2 driver to keep its /dev/video node around Note that b) means that the normal disconnect handler should still be called after a soft reconnect on a real disconnect. In some sense the disconnect callback for usb-storage already _is_ soft. Although the driver cannot refuse the disconnect, it _can_ continue to communicate with the device until the callback returns. (As it happens, usb-storage _doesn't_ do any further communication with the device. This is mostly for historical reasons, to compensate for shortcomings in the SCSI stack in earlier kernel versions. On the other hand, there really isn't much that you would want to send to a mass-storage device during a soft disconnect. Perhaps tell it to flush its cache out to the storage medium -- but if there are no open file handles for the device and no mounted filesystems then the cache will already be flushed.) 2) A usb_driver soft_reconnect callback to match the soft_disconnect 3) A mechanism for a usb_driver to signal a usbfs fd owner of the device it would like the device back. So for example the gvfs mount can be automatically unmounted (if not busy). This also should be handled in userspace. USB drivers never want back a device they are no longer bound to -- in fact, the device model used throughout the kernel makes this whole idea meaningless. Device drivers don't want devices back. Rather, _users_
Re: Improving kernel - userspace (usbfs) usb device hand off
Em 10-06-2011 11:48, Alan Stern escreveu: On Fri, 10 Jun 2011, Hans de Goede wrote: As Felipe has mentioned, this sounds like the sort of problem that can better be solved in userspace. A dual-mode device like the one you describe really is either a still-cam or a webcam, never both at the same time. Hence what users need is a utility program to switch modes (by loading/unloading the appropriate programs or drivers). Unloading a driver in order to access the hardware via userspace? This sounds a very bad idea do me. What happens if another hardware is using the same driver? Cheers, Mauro. -- 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
Re: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Mauro Carvalho Chehab wrote: Em 10-06-2011 11:48, Alan Stern escreveu: On Fri, 10 Jun 2011, Hans de Goede wrote: As Felipe has mentioned, this sounds like the sort of problem that can better be solved in userspace. A dual-mode device like the one you describe really is either a still-cam or a webcam, never both at the same time. Hence what users need is a utility program to switch modes (by loading/unloading the appropriate programs or drivers). Unloading a driver in order to access the hardware via userspace? This sounds a very bad idea do me. What happens if another hardware is using the same driver? A kernel driver wouldn't have to be unloaded. It could simply be unbound from the device via sysfs or usbfs. Alan STern -- 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
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 01:16:47PM -0500, Theodore Kilgore wrote: As I have been involved in writing the drivers (both the kernel and the libgphoto2 drivers) for many of the affected cameras, perhaps I should expand on this problem. There are lots of responses to this original message of Hans. I will try to take some of their comments into account, below. First, some background. 1. All of the cameras in question have only one USB Vendor:Product number. In this sense, they are not good citizens which have different Product there's nothing in the USB spec that says you need different product IDs for different modes of operation. No matter if it's still or webcam configuration, the underlying function is the same: capture images using a set of lenses and image sensor. numbers for the two distinct modes of functioning. Thus, the problems are from that standpoint unavoidable. I don't see any problems in this situation. If, for that particular product, webcam and still image functionality are mutually exclusive, then that's how the product (and their drivers) have to work. If the linux community decided to put webcam functionality in kernel and still image functionality on a completely separate driver, that's entirely our problem. 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) 3. The current state of affairs is an advance on (2) but it is still inelegant. What happens now is, libusb has been revised in such a way that the kernel module is disabled (though still present) if a userspace driver (libgphoto2) wants to access the device (the camera). If it is desired to do video streaming after that, the camera needs to be re-plugged, which then causes the module to be automatically re-loaded. It's still wrong. This should be just another USB_REQ_SET_CONFIGURATION(). If this is was just one single driver, you could easily do that. 4. Hans is absolutely correct about the problem with certain Gnome apps (and certain distros which blindly use them), which load up the libgphoto2 driver for the camera as soon as it is detected. The consequence (cf. item 3) is that the camera can never be used as a webcam. The only solution to that problem is to disable the automatic loading of the libgphoto2 driver. Or, to move the libgphoto2 driver to kernel, combine it in the same driver that handles streaming. No ? 5. It could be said that those who came up with the user-friendly solution described in (4) were not very clever, and perhaps they ought to fix their own mess. I would strongly agree that they ought to have thought before coding, as the result is not user-friendly in the least. I agree here 6. The question has been asked whether the cameras are always using the same interface. Typically, yes. The same altsetting? That depends on the camera. Some of them use isochronous transport for streaming, and some of them rely exclusively upon bulk transport. Those which use bulk transport only are confined to altsetting 0. the transfer type or the way the configurations are setup shouldn't matter much for the end functionality. Some possible solutions? Well, first of all it needs to be understood that the problem originates as a bad feature of something good, namely the rigid separation of kernelspace and userspace functionality which is an integral part of the Linux security model. Some other operating systems are not so careful, and thus they do not have a problem about supporting dual-mode hardware. You'd need to describe this fully. What's the problem in having one driver handle all modes of operation of that particular camera ? Sounds like a decision from V4L2 folks not to take still image cameras in kernel. Am I wrong ? Second, it appears to me that the problem is most appropriately addressed from the userspace side and perhaps also from the kernelspace side. In userspace, it would be a really good idea if those who are attempting to write user-friendly apps and to create user-friendly distros would actually learn some of the basics of Linux, such as the rudiments of the security model. Since dual-mode cameras are known to exist, it would have been appropriate, when one is detected, to pop up a dialog window which asks the user to choose a webcam app or a stillcam app. Even this minor innovation would stop a lot of
Re: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Hans de Goede wrote: Hi all, The current API for managing kernel - userspace is a bit rough around the edges, so I would like to discuss extending the API. [...] 2) So called dual mode cameras are (cheap) stillcams often even without an lcdscreen viewfinder, and battery backed sram instead of flash, which double as a webcam. We have drivers for both the stillcam function of these (in libgphoto2, so using usbfs) as well as for the webcam function (v4l2 kernel drivers). These drivers work well, and are mature. Yet the user experience is rather poor. Under gnome the still-cam contents will be automatically be made available as a drive using a gvfs-gphoto2 fuse mount. This however involves sending a disconnect to the v4l2 kernel driver, and thus the /dev/video# node disappearing. So if a user wants to use the device as a webcam he/she needs to first go to nautilus and unmount the gvfs mount. Until that is done the user will simply get a message from an app like cheese that he has no webcam, not even an ebusy error, just that he has no such device. Again not good. [...] As I have been involved in writing the drivers (both the kernel and the libgphoto2 drivers) for many of the affected cameras, perhaps I should expand on this problem. There are lots of responses to this original message of Hans. I will try to take some of their comments into account, below. First, some background. 1. All of the cameras in question have only one USB Vendor:Product number. In this sense, they are not good citizens which have different Product numbers for the two distinct modes of functioning. Thus, the problems are from that standpoint unavoidable. 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. 3. The current state of affairs is an advance on (2) but it is still inelegant. What happens now is, libusb has been revised in such a way that the kernel module is disabled (though still present) if a userspace driver (libgphoto2) wants to access the device (the camera). If it is desired to do video streaming after that, the camera needs to be re-plugged, which then causes the module to be automatically re-loaded. 4. Hans is absolutely correct about the problem with certain Gnome apps (and certain distros which blindly use them), which load up the libgphoto2 driver for the camera as soon as it is detected. The consequence (cf. item 3) is that the camera can never be used as a webcam. The only solution to that problem is to disable the automatic loading of the libgphoto2 driver. 5. It could be said that those who came up with the user-friendly solution described in (4) were not very clever, and perhaps they ought to fix their own mess. I would strongly agree that they ought to have thought before coding, as the result is not user-friendly in the least. 6. The question has been asked whether the cameras are always using the same interface. Typically, yes. The same altsetting? That depends on the camera. Some of them use isochronous transport for streaming, and some of them rely exclusively upon bulk transport. Those which use bulk transport only are confined to altsetting 0. Some possible solutions? Well, first of all it needs to be understood that the problem originates as a bad feature of something good, namely the rigid separation of kernelspace and userspace functionality which is an integral part of the Linux security model. Some other operating systems are not so careful, and thus they do not have a problem about supporting dual-mode hardware. Second, it appears to me that the problem is most appropriately addressed from the userspace side and perhaps also from the kernelspace side. In userspace, it would be a really good idea if those who are attempting to write user-friendly apps and to create user-friendly distros would actually learn some of the basics of Linux, such as the rudiments of the security model. Since dual-mode cameras are known to exist, it would have been appropriate, when one is detected, to pop up a dialog window which asks the user to choose a webcam app or a stillcam app. Even this minor innovation would stop a lot of user grief. Frankly, I am mystified that this was not done. This still leaves the problem (see item 3, above) that a dual-mode camera needs to be re-plugged in order to re-enable the access to /dev/video* if it has been used in stillcam mode. If it is possible to do a re-plug in software, this would help a lot. It does not matter if the re-plug
Re: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Felipe Balbi wrote: I don't see any problems in this situation. If, for that particular product, webcam and still image functionality are mutually exclusive, then that's how the product (and their drivers) have to work. If the linux community decided to put webcam functionality in kernel and still image functionality on a completely separate driver, that's entirely our problem. And the problem is how to coordinate the two of them. 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) I think the problem may be that the PTP protocol used in the still-cam mode isn't suitable for a kernel driver. Or if it is suitable, it would have to be something like a shared-filesystem driver -- nothing like a video driver. You certainly wouldn't want to put it in V4L2. Or, to move the libgphoto2 driver to kernel, combine it in the same driver that handles streaming. No ? No. Something else is needed. Alan Stern -- 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
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 05:18:39PM -0400, Alan Stern wrote: 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) I think the problem may be that the PTP protocol used in the still-cam mode isn't suitable for a kernel driver. Or if it is suitable, it would have to be something like a shared-filesystem driver -- nothing like a video driver. You certainly wouldn't want to put it in V4L2. ach true.. Had forgotten that detail. Needs more thinking. -- balbi signature.asc Description: Digital signature
Re: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Felipe Balbi wrote: Hi, On Fri, Jun 10, 2011 at 01:16:47PM -0500, Theodore Kilgore wrote: As I have been involved in writing the drivers (both the kernel and the libgphoto2 drivers) for many of the affected cameras, perhaps I should expand on this problem. There are lots of responses to this original message of Hans. I will try to take some of their comments into account, below. First, some background. 1. All of the cameras in question have only one USB Vendor:Product number. In this sense, they are not good citizens which have different Product there's nothing in the USB spec that says you need different product IDs for different modes of operation. No matter if it's still or webcam configuration, the underlying function is the same: capture images using a set of lenses and image sensor. True, true. But I will add that most of these cameras are Class 255, Subclass 255, Protocol 255 (Proprietary, Proprietary, Proprietary). numbers for the two distinct modes of functioning. Thus, the problems are from that standpoint unavoidable. I don't see any problems in this situation. If, for that particular product, webcam and still image functionality are mutually exclusive, then that's how the product (and their drivers) have to work. Yes. If the linux community decided to put webcam functionality in kernel and still image functionality on a completely separate driver, that's entirely our problem. As I understand, the basic reason why webcam functionality needs to be in the kernel is speed. Quick reaction time, and faster data transmission. Most but not all webcams use isochronous data transport. The ones which do not, cannot get as high a rate of frames per second. Isochronous data transport has historically seemed to need kernel support in order to work properly. Related to this, libusb has not supported isochronous data transport. But still cameras use bulk transport. This is natural because one needs to move data which is stored on the camera to a place on the computer where it can be processed (if needed) and stored. There is no impediment to userspace talking to a USB device, so why not go ahead and do the job that way if the kernel is not needed? The second thing to mention is that libgphoto2 at this point is supporting well over 1,000 cameras. True, there are not 1,000 driver libraries, but there are quite a few. My impression is that nobody wants to put stuff like that in the kernel unless it is absolutely necessary, just because some of those cameras are dual-mode cameras. Don't people complain on a fairly regular basis about kernel code bloat? 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) See above. 3. The current state of affairs is an advance on (2) but it is still inelegant. What happens now is, libusb has been revised in such a way that the kernel module is disabled (though still present) if a userspace driver (libgphoto2) wants to access the device (the camera). If it is desired to do video streaming after that, the camera needs to be re-plugged, which then causes the module to be automatically re-loaded. It's still wrong. This should be just another USB_REQ_SET_CONFIGURATION(). If this is was just one single driver, you could easily do that. Well, I think it ought to be possible anyway. Up to that point, I agree. Though I confess I do not exactly know how. 4. Hans is absolutely correct about the problem with certain Gnome apps (and certain distros which blindly use them), which load up the libgphoto2 driver for the camera as soon as it is detected. The consequence (cf. item 3) is that the camera can never be used as a webcam. The only solution to that problem is to disable the automatic loading of the libgphoto2 driver. I would only add to this, that it is not pleasant to have to deal with frustrated users. At this point, my usual advice is that this is a distro problem. Ask your distro for help. Or, to move the libgphoto2 driver to kernel, combine it in the same driver that handles streaming. No ? See above. 5. It could be said that those who came up with the user-friendly solution described in (4) were not very clever, and perhaps they ought to fix their own mess. I would strongly agree that they ought to have
Re: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Alan Stern wrote: On Fri, 10 Jun 2011, Felipe Balbi wrote: I don't see any problems in this situation. If, for that particular product, webcam and still image functionality are mutually exclusive, then that's how the product (and their drivers) have to work. If the linux community decided to put webcam functionality in kernel and still image functionality on a completely separate driver, that's entirely our problem. And the problem is how to coordinate the two of them. 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) I think the problem may be that the PTP protocol used in the still-cam mode isn't suitable for a kernel driver. Or if it is suitable, it would have to be something like a shared-filesystem driver -- nothing like a video driver. You certainly wouldn't want to put it in V4L2. Or, to move the libgphoto2 driver to kernel, combine it in the same driver that handles streaming. No ? No. Something else is needed. Alan Stern Agreed. Something else is needed. But what? Also, very good point about PTP. Theodore Kilgore -- 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
Re: Improving kernel - userspace (usbfs) usb device hand off
On Sat, Jun 11, 2011 at 6:43 AM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: I do not believe that we have found the optimal solution, yet. The ideal thing would be some kind of hack which allows the kernel to be used when it is needed, and when it is not needed it does not interfere. Just wondering if you can use libusb-1.0 for the user space still image functionality. libusb-1.0 offers the following functions to do that for you under Linux. int libusb_kernel_driver_active (libusb_device_handle *dev, int interface) Determine if a kernel driver is active on an interface. int libusb_detach_kernel_driver (libusb_device_handle *dev, int interface) Detach a kernel driver from an interface. int libusb_attach_kernel_driver (libusb_device_handle *dev, int interface) Re-attach an interface's kernel driver, which was previously detached using libusb_detach_kernel_driver(). So you can detach the kernel v4l2 driver at the beginning and later re-attach it when you finish. -- Xiaofan -- 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
