On Mon, 30 Jan 2012 12:55:48 +0100 Nicolas Bourdaud <nicolas.bourd...@gmail.com> wrote:
> Hi all, > Hi Nicolas, > 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: > I am the gspca_kinect author, and a minor contributor to libfreenect :) Short version: solution 0, update libfreenect to the latest version, read below. :) > - 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 The libfreenect part is already implemented, see https://github.com/OpenKinect/libfreenect/commit/834af351e6d1697c5ad71c9532993d57928aaf16 If libusb needs fixing, that I don't know, sharing a USB device via _libusb_ across different apps looks strange, quoting Peter Stuge from the thread you referenced: I also think the problems you ran into would be valid for any USB device that tries to be shared by multiple applications. This isn't really a use case that USB supports, simple as that. Of course it can still be attempted, but YMMV. :) > - 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? > I'd say update libfreenect to the latest version, which as a matter of fact is adopting solution 2, and live with the limitations of libusb. IMHO, generally, downstream should track more closely upstream releases and maybe communicate with upstream directly, this looks like a question for openkin...@googlegroups.com It was just a coincidence that I both happen to follow OpenKinect _and_ am on debian-mentors. That said: thanks a lot for packaging libfreenect for Debian. Regards, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?
pgpclDA0s8W4Z.pgp
Description: PGP signature
