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
