On Tuesday 09 August 2011, Hans de Goede wrote: > Hi, > > On 08/09/2011 04:19 PM, Alan Stern wrote: > > Does it really make sense to combine 5 drivers into one? > > Right, that is not the plan. The plan is to simply stop having 2 drivers > for 1 logical (and physical) block. So we go from 10 drivers, 5 stillcam > + 5 webcam, to just 5 drivers. We will also likely be able to share > code between the code for the 2 functionalities for things like generic > set / get register functions, initialization, etc. > Unfortunately as Theodore recently pointed out you don't go from 10 to 5, you go from 10 to 10 where 5 of the new 10 are only used on Win32, FreeBSD and OSX (but they aren't any simpler because they still rely on libusb) and the other 5 that are only used on Linux become significantly more complicated than they currently are. It has also just occured to me that it might be possible to solve the issues we are facing just in the kernel. At the moment when the kernel performs a USBDEVFS_DISCONNECT it keeps the kernel driver locked out until userspace performs a USBDEVFS_CONNECT. If the kernel reattached the kernel driver when the device file was closed then, as gvfs doesn't keep the file open the biggest current issue would be solved instantly. If a mechanism could be found to prevent USBDEVFS_DISCONNECT from succeeding when the corresponding /dev/videox file was open then that would seem to be a reasonable solution. Hans had expressed the opinion that merely having the device open to control the camera not to stream shouldn't prevent stillcam operation - I disagree because if you are setting up the controls you are probably already streaming so you can see what you are doing and if not you are probably about to. Of course changing the behaviour of USBDEVFS_DISCONNECT is not something to be done lightly. I don't know how many other users there are for it and if the current behaviour is actually correct for any of them. Cleaning up on file close does have the useful side effect though that applications no longer need to worry about the fact that even if they clean up properly on a normal exit, if they crash they leave the kernel driver permanently disabled Regards Adam -- 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
