On Tue, 07 Dec 2010 12:29:31 +0100 Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > On 12/06/2010 10: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 think that being able to use the kinect as just a webcam in apps like cheese, > skype and google chat is a major advantage of the kernel driver. I also > think that in the long run it is not useful to have 2 different drivers. > Well, keep in mind that libfreenect meant to be a postable layer across different platforms, so the libusb backend would be around even if the projects ended up not using it on 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). > > Currently gspca cannot handle 2 streaming endpoints / 2 video nodes for 1 > usb device. I've been thinking about this and I think that the simplest solution > is to simply pretend the kinects video functionality consists of 2 different > devices / usb interfaces in a multifunction device. Even though it does not > what I'm proposing is for the kinect driver to call: gspca_dev_probe twice with > 2 different sd_desc structures, thus creating 2 /dev/video nodes, framequeues and > isoc management variables. > > This means that the alt_xfer function in gspca.c needs to be changed to not > always return the first isoc ep. We need to add an ep_nr variable to the > cam struct and when that is set alt_xfer should search for the ep with that > number and return that (unless the wMaxPacketSize for that ep is 0 in the > current alt setting in which case NULL should be returned). > Thanks for these directions, it doesn't sound too hard to do. > > - 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). > > I think 2 separate nodes is easiest, also see above. > That's the way I am going for now. 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?
Attachment:
pgpfd1sUJy4Ei.pgp
Description: PGP signature
