Hi Yaroslav!
The package starts to be in good shape, here are the last modifications:
- updated to upstream 0.1.2 (+dfsg)
- fixes shlibs warnings (not for python module)
- add -doc package
- fixes udev rules
- written backport patches
As such, the package is almost over. I have not touched the python
part: I am definitively not expert in python module so I prefer you to
check that the upstream change and conversion to dh sequencer has not
broken its build.
I am verifying the backports build and it seems to work fine: so far it
build on squeeze, testing and sid
Ok now the issues, one small, one bigger:
The udev rules were broken, so I needed to update them, especially, the
permission of "all" is updated by another udev rule that I have not yet
identified but anyways, I am not sure it was a good practice to grant
access to any user. Instead I set the group to plugdev, so that any user
of plugdev (normal desktop user are usually) can access and this is not
altered by any other rule. My question is now: do you think it make
sense? If so does the plugdev group make sense as well? If you don't
know, I can ask on mentor mailing list to have the opinion of the community.
The second issue is more serious. In the current state of the package,
the library cannot be used out of the box on modern distribution like
debian wheezy or ubuntu oneiric: 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). This means that when the kinect is
connected, that module claims the USB interface of the camera, thus
making it unavailable for libfreenect (it is not a problem of permission
like before: accessing through libfreenect return device busy). This
problem affects all version including the current version of the package
(the one that entered in testing today). Now I have 3 solutions but none
are good:
- solution 1: installing libfreenect0.1 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 libfreenect which detaches the kernel
driver whenever the kinect is accessed through libfreenect and
reattaches it when it closes. This is not a hack but a normal operation
that libusb provides (actually usbfs provides the ioctl). The problem is
that libusb is badly designed and if we reopen the same device from
another libfreenect instance, the first instance will loose its
connection without notice (actually it is bad, what is expect is 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 explanation.
- solution 3: Status quo. 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 people will install the package and it will
not work without root intervention. It also requires them to read the
doc folder to understand what is going on (not everybody read the manual
:-( ). This is nevertheless the solution that is currently adopted for
consistency with previous versions.
So I would like to know your opinion about this. We may also ask the
question on the Debian mailing lists.
Cheers,
Nicolas
signature.asc
Description: OpenPGP digital signature
