OpenKinect repository and libusb-win32 branch status

[Kyle Machulis]

OpenKinect repo -

Thanks to JoshBlake, the OpenKinect github organization has been set up at

http://www.github.com/OpenKinect/

So, if you're going to fork something, fork this. :)

Currently, there is one repo that contains a combination of marcan's repo, ofTheo's OS X fixes, and JoshBlake's C# code. I did the merge and updates, tested on linux and OS X and added platform include guards where needed, and updated the cmake to make it build those platforms with no changes required. There's more info on this in the repo README.

More repos may come up later pertaining to applications at a later time.

Win32 Driver Status - 

Earlier today (after much yelling in the channel), it was learned that libusb-win32, as of the 1.2.0.0 release from about 6 weeks ago, allows asynchronous iso transfers. "Majority" on the IRC channel started to do a code port, but left before sending code around. Word when he left was that things opened but didn't do much more.

I went ahead and tried my own port of the libusb-win32 stuff this evening, with somewhat limited success. First off, my current, insanely messy work is on the win32 branch of the openkinect repo:

https://github.com/openkinect/OpenKinect/tree/win32

What I've found so far:

- libusb-win32 1.2.0.0 binary package off the website is what I'm using for linking

- I used the INF files that are in the platform/windows directory, provided by JoshBlake and rrivera. These seem to work.

- LED access works without problem. There's a commented out block of code that works as a sanity check for this.

- Opening the camera and setting config/claiming interface works.

The issues start when you try to send control messages. Basically, libusb-win32 requires timeouts to not be 0 (I ran into this problem with libtrancevibe in 2006, guess it's still there). If you set timeouts to 0, you get an -116 error (I/O terminated due to application or thread termination). If you set the timeouts on usb_control_msg to 10, the first control request (0x80, 18 byte request. marcan, what is this? I don't see it in the ladyada dumps?) fails, then the next 5 or so init requests pass, then everything after that fails again after that. At this point, replugging the camera is required for further work. If you set the timeouts too high (for instance, to 100), you get a -5 (device disconnected). 

This does not make me super hopeful about libusb-win32 being used for the iso stuff, if it's this bitchy about timing on something as simple as control messages, but I could also be doing something blatantly wrong here. It's been many years since I've done libusb-0.1 work.

There's talk on their webpage of development of a libusb-1.0 core based on the libusb0.sys driver. Might poke around the libusb-1.0 repos and see what the status on this is.

And here's hoping that like the last two nights, things are all fixed when I wake up in the morning. :)

Kyle

[Florian Echtler]

Thanks - one really small wish: can we make libfreenect shared by
default? Makes integration into other stuff (i.e., libTISCH :-) much
easier. Attached patch should do it...

Thanks,
Yours,
Florian

[Theodore Watson]

one note - on both macam and libfreenect that first control message also returns an error (pipe stalled) - but that doesn't seem to matter.

was still able to get the camera to init just fine. 

[Hector Martin]

That's what the original Xbox log shows too (the Xbox sends that control
transfer and also gets a stall) ;)

--
Hector Martin (hec...@marcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc