|| ||Antonio Ospite <email@example.com> |
|| ||OpenKinect <firstname.lastname@example.org> |
|| ||Kinect sensor and Linux kernel driver. |
|| ||Mon, 6 Dec 2010 22:18:47 +0100|
|| ||email@example.com, Steven Toth <firstname.lastname@example.org>|
|| ||Article, Thread
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:
And here's some background about it (meant also for non OpenKinect
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
* 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.
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?