PS4-Eye-Driver Hitting ERROR_INVALID_USER_BUFFER on iso transfers in Win10

Hello! First off, thanks for your investigation into making this library work in Win10.

I'm currently trying to incorporate the ps4eye camera library into PSMoveService. I can get the firmware to successfully upload and the camera to initialize, but the iso transfers are failling with ERROR_INVALID_USER_BUFFER:

[ 3.489788] [000029a4] libusb: debug [libusb_submit_transfer] transfer 00AF4590
[ 3.489788] [000029a4] libusb: debug [winusbx_submit_iso_transfer] matched endpoint 81 with interface 1
[ 3.490791] [000029a4] libusb: debug [winusbx_submit_iso_transfer] reading 8 iso packets
[ 3.490791] [000029a4] libusb: debug [usbi_add_pollfd] add fd 1 events 1
[ 3.490791] [000029a4] libusb: debug [windows_handle_events] checking fd 2 with revents = 0001
[ 3.490791] [000029a4] libusb: debug [usbi_remove_pollfd] remove fd 2
[ 3.490791] [000029a4] libusb: debug [windows_transfer_callback] handling I/O completion with errcode 1784, size 0
[ 3.490791] [000029a4] libusb: error [windows_transfer_callback] detected I/O error 1784: [1784] The supplied user buffer is not valid for the requested operation.

I'm curious if this was an issue you hit as well. It's entirely possible I messed up my integration of Josh Blake's winiso branch, but I figure it couldn't hurt to check with someone else who tried to make this work in windows as well.

Here were the steps I took to get up and running: (This is from https://github.com/cboulay/PSMoveService/issues/35)

I made a fork of the most recent version of libusb and added the following cherry picked changes from JoshBlake's libusbx fork

Adding isosynchronous transfer support via libusbk - 53e208c138883d0335d4422d61db024225ed2df4
Adding super speed iso synchronous length handling - c20fdf36968b3b3891ef95dc11eaedfdefd8d05a

I made a fork of PS4EyeCam with the following changes to make it build

A few simple Win32 compile error fixes: 56148a6641eb8aa7cd65a232ae77b5d7d6cb7cf9
Added SDL2 and my fork of libusb as submodules - cced8695901833138d7f35112af85c41ec036b2a
Added a simple SDL camera test app that mirrors what the other two test apps do along with cmake scripts and batch files to build everything - bdccecdea5af32addf73ee10e03f51d1549fda2f

Connected my ps4 camera to my pc and made sure it just showed the USB Boot entry:
Installed lib-usb onto the USB boot device
Launced SDLTest, my simple SDL test app built using PS4EyeCam, which installs the firmware on the camera. Windows then appears to install some new drivers for a camera in response.
Select the OV580 composite parent entry in Zadig and install libusbK
Launch SDLTest again which connects to the camera and attempts to setup mode 1 and stream camera data.

I've tested this same code in Linux and can get the camera transferring video so I believe the problem is at least isolated to libusb's windows specific code.

Jul 25 '16 18:07 HipsterSloth

I'm running into this same issue with the libfreenect2. Posting here to stay synchronized! EDIT: The solution is to apply this https://github.com/JoshBlake/libusbx/commit/c5b0af436ac7279d4b59406e04f1792bf445e40c AND this fix: https://github.com/JoshBlake/libusbx/commit/1c7421157a5f6a3726d9f39ed7cad281557c9e0a

Dec 29 '16 02:12 cuisinart

@HipsterSloth Hey, I'm currently trying to use your branches of libusb and PS4EyeCam on Windows 10 and I'm running into the same issue you were:

libusb: error [windows_transfer_callback] detected I/O error 1784: [1784] The supplied user buffer is not valid for the requested operation.

I recompiled your libusb branch, which as I understood it should fix this issue, as 64 bit. I've put the output just before that error at https://pastebin.com/XX4AdRy7.

Do you have any advice?

Thanks!

Edit: I also tried building your SDL test app on two separate computers and both of them have the same issue.

Jul 11 '17 19:07 colejd

@seieibob Turns out I didn't have that second JoshBlake libusb fix (JoshBlake/libusbx@1c74211) incorporated into my libusb fork. I just added that change, updated the submodule reference to libusb in my fork of PS4EyeCam, and fixed up some of my build scripts. Unfortunately now when I try to run the sdl test tool I am now unable to to bind interface 1 on the camera. After the firmware uploads it looks like only interface 0 is showing up on the camera.

Do you see interface 0 and 1 for the camera in Zadig? Also would you mind syncing latest on my fork and see if that makes any difference?

Jul 12 '17 07:07 HipsterSloth

I'd be happy to help in any way I can. I'm hoping to use this for my master's research, so I'm definitely interested in getting this working.

I updated to your latest version of libusb and I'm having a different problem now. I now get libusb: error [windows_transfer_callback] detected I/O error 87: [87] The parameter is incorrect. and the program crashes at the following (in my own program):

capture

I had to disable the libusb_detach_kernel_driver portion of ps4eye.cpp (link), otherwise I get "not supported" errors. Apparently the detach code isn't supported in Windows. Additionally, I had to disable this line after enabling debug messages since ctrl.bInterfaceNumber isn't initialized.

I tried doing all this on a fresh computer to check about the interfaces. USB_BOOT shows fine, and when uploading the firmware, Windows reconnects to the camera and automatically installs a system driver:

capture

At this point, only Interface 0 was visible, same as your situation. I tried running the SDL test tool and it tells me that the device can't be opened, which I gather is fine since I'm supposed to replace the composite parent with libusbK.

After replacing the composite parent with libusbK, I get the [windows_transfer_callback] error above when using the SDL test tool, but only when running in Release configuration. In Debug, the program will run without complaining, but the screen is black.

Let me know if there's any other way I can help!

Jul 12 '17 16:07 colejd

@seieibob

At this point, only Interface 0 was visible, same as your situation. I tried running the SDL test tool and it tells me that the device can't be opened, which I gather is fine since I'm supposed to replace the composite parent with libusbK.

Ohhh right. I forgot about having to update the driver for the composite device. It's been a while since I've worked on this. Once I did that step I was able to get past the lack of the second interface.

I updated to your latest version of libusb and I'm having a different problem now. I now get libusb: error [windows_transfer_callback] detected I/O error 87: [87] The parameter is incorrect. and the program crashes at the following (in my own program):

I'm having that heap memory corruption in that same location. I was also having another heap corruption issue in SDL event handling code. This makes me think either I didn't integration Josh Blake's second change over correctly or there is just a bug with how his change is writing to the iso transfer context buffers. I tried looking at this for a bit but couldn't figure out where the heap corruption is coming from. This will take some more investigation it looks like.

I had to disable the libusb_detach_kernel_driver portion of ps4eye.cpp (link), otherwise I get "not supported" errors. Apparently the detach code isn't supported in Windows. Additionally, I had to disable this line after enabling debug messages since ctrl.bInterfaceNumber isn't initialized.

Ah sorry. I forgot I had to disable those locally myself as well. I'll post an update with those changes.

I'd be happy to help in any way I can. I'm hoping to use this for my master's research, so I'm definitely interested in getting this working.

Just out of curiosity, is your master's research relate to using this particular camera or would any stereo camera work (like this one: https://www.amazon.com/gp/product/B00VG32EC2).

Jul 13 '17 07:07 HipsterSloth

I am also having the heap corruption issue. Sometimes it just breaks cleanly in VS, and other times I'll get a popup from Windows itself about the heap corruption; it seems to be random which one I get.

Thank you for linking the cameras. My research involves creating a wearable AR device, so I need a fairly high framerate and synchronization on the cameras, which means I'm fairly limited in what I can use. I'm actually using a pair of PS3 cameras right now. I need at least 60 Hz, so unfortunately the cameras you linked won't work for my purposes. Thanks for pointing me to them though!

Jul 13 '17 16:07 colejd