Hi all, Recently I have faced a problem of conflict while packaging libfreenect which is the userspace driver using libusb-1.0 for the Microsoft Kinect. I mention the name of the package for having a real example but the problem exists for any USB userspace driver while a kernel module implements part of the same functionalities. Let me describe the issue: Since version 3.0, the linux kernel includes a module that provides a v4l2 driver for the kinect camera (it is the module gspca_kinect). But it is for video stream only. The depth estimate which is one of the feature why people use a kinect device, can be fetched only through libfreenect. The availability of this kernel module means that when the kinect is connected, that module claims the USB interface of the camera, thus making it unavailable for libfreenect. Now I have 3 solutions but none are good: - solution 1: installing libfreenect package installs a modprobe rule which blacklist the module gspca_kinect. But it makes the v4l2 interface unavailable which is bad for those who want to use it. - solution 2: write a patch to upstream which detaches the kernel driver whenever the kinect is accessed through libfreenect and reattaches it when it closes (libusb_detach_kernel_driver). The problem is that libusb-1.0 is badly designed and if we reopen the same device using the userspace driver, the first instance will loose its connection without notice (The sane behavior would have been the second instance fails). See > http://libusb.6.n5.nabble.com/libusb-detach-kernel-driver-also-has-the-side-effect-of-libusb-release-interface-td3267040.html for exaplantion - solution 3: we don't do anything, just inform users in the README.Debian about the problem and that they need to detach the kernel module by themselves using rmmod or by blacklisting the module. This solution is not nice since in this situation, people will install a package which is unusable without intervention (even worse: without root intervention). Me and the other maintainers of libfreenect have currently decided to go for a hybrid solution that uses a debconf script asking whether or not the kernel module should be blacklisted. But the choice of the default action (important for background install/upgrade) comes to the same dilemma as before. So I am asking you, what is the best way to deal with this kind of issue? Regards, Nicolas
Attachment:
signature.asc
Description: OpenPGP digital signature