On 12/06/2010 04:18 PM, Antonio Ospite wrote: > 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). I've got a patchset in the works for this, just trying to view Y16 from userspace first... > * 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? embedded applications may find this helpful... > 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. always a good idea. I'm pretty sure the motion project [1] could make use of a v4l device that spits out smoothed depth data... > - 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). wip. > - 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). There is a timestamp field with every frame passed on by the kinect, can that be passed up to v4l? Also, if we decide to stay with two video nodes, some udev magic could create: /dev/kinect/depth -> ../videoX /dev/kinect/camera -> ../videoY /dev/kinect/ir -> ../videoZ ... For consistent naming. thx, Jason. [1] http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome -- 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
