On Monday, December 06, 2010 22:18:47 Antonio Ospite wrote: > 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? How do other accelerometer drivers do this? > The only reason for that is to use the data in already > existing applications. And what about led and motor? We are talking about LED(s?) on the webcam and the motor controlling the webcam? That is typically also handled via v4l2, usually by the control API. > > 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. In general webcam drivers are part of the kernel. For some classes of webcams additional userspace libraries exist that add functionality specific to those webcams (UVC webcams are a good example of this). It sounds like this might be a good approach as well for this device as well. Basically the idea is that the kernel provides the access to the hardware and standard video capture functionality so that the device can be used by any standard v4l capture application. Additional hardware-specific functionality can be provided by a userspace library that cooperates with the kernel driver. > - 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). My gut feeling is that a combined RGB-D stream is only feasible if the two streams as received from the hardware are completely in sync. If they are in sync, then it would probably simplify the driver logic to output a combined planar RGB+D format (one plane of RGB and one of D). Otherwise two nodes are probably better. > - If a combined format would be chosen, settle on a format usable also > by future RGB-D devices. In general the video format should match what the hardware supplies. Any format conversions should take place in libv4lconvert. Format conversions do not belong in kernel space, that's much better done in userspace. Hope this helps. Sounds like this is a cool device :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
