Conflict between userspace driver and kernel driver module

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

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/libus...67040.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






To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/4F268544.3070702@gmail.com