Hi, a first, very simplified, linux kernel driver for the Kinect sensor device is now available, so you now can use it as a ridiculously expensive webcam with any v4l2 application.
Here's the code: http://git.ao2.it/gspca_kinect.git/ And here's some background about it (meant also for non OpenKinect folks): http://ao2.it/blog/2010/12/06/kinect-linux-kernel-driver As you can see this driver is just some "advanced copy&paste" from libfreenect, plus reducing the packets scan routine to the bare minimum. Taking some code from libfreenect should be OK as it comes under GPLv2 (dual-licensed with an Apache license) but let me know if you think there could be any issues. The gspca framework proved itself very precious once again —thanks Jean-François—, for this simple proof-of-concept driver it took care of the whole isoc transfer setup for us. Now the hard part begins, here's a loose TODO-list: - Discuss the "fragmentation problem": * the webcam kernel driver and the libusb backend of libfreenect are not going to conflict each other in practice, but code duplication could be avoided to some degree; we could start listing the advantages and disadvantages of a v4l2 backend opposed to a libusb backend for video data in libfreenct (don't think in terms of userspace/kernelspace for now). * Would exposing the accelerometer as an input device make sense too? The only reason for that is to use the data in already existing applications. And what about led and motor? If we agree that the kernel driver approach is not too dangerous for libfreenect's future, than we could start talking about submitting code to mainline linux. - Check if gspca can handle two video nodes for the same USB device in a single driver (Kinect sensor uses ep 0x81 for color data and ep 0x82 for depth data). - Decide if we want two separate video nodes, or a combined RGB-D data stream coming from a single video device node. (I haven't even looked at the synchronization logic yet). - If a combined format would be chosen, settle on a format usable also by future RGB-D devices. Comment and Critics more than welcomed. Regards, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 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?
pgpCZYi3WUhBE.pgp
Description: PGP signature
