PSVRConfigTool not discovering HMD/DS4. (Do find cameras/BlueTooth radio.)

[m-7761]

The PSVR is not appearing. It may be because there isn't the MorpheusHMDConfig.json file among the others. Neither is a connected DS4 found.

MorpheusHMD::open is entered. I see a drivers folder that has WinUSB drivers. I assume these are identical to the ones I've installed for using PSVRToolbox. I would like it very much if a project can be developed to supersede PSVRToolbox. It's defunct, and C++ is beats C#.

open tries to load this JSON file, that is not in the folder. I don't know if that's the only thing standing in its way.

I would like to see the SIXAXIS in the DS4 work too. Can it work over USB? I tend to keep my BlueTooth receiver off unless using it. Currently it's not showing up.

[2019-03-06 11:34:57.165]: main - Starting PSVRService v0.1.0.0
[2019-03-06 11:34:57.168]: USBAsyncRequestManager::startup - Requested LibUSBApi
[2019-03-06 11:34:57.170]: USBAsyncRequestManager::startup - Creating LibUSBApi
[2019-03-06 11:34:57.179]: USBAsyncRequestManager::startup - Initialized USB API
[2019-03-06 11:34:57.181]: USBAsyncRequestManager::startup - Starting USB event thread
[2019-03-06 11:34:57.187]: DeviceManager::startup - Platform Hotplug API is ENABLED
[2019-03-06 11:34:57.207]: bluetooth_get_host_address - Found a bluetooth radio
[2019-03-06 11:34:57.214]: bluetooth_get_host_address - Retrieved radio info
libusb: error [init_device] device '\\.\USB#VID_054C&PID_09AF&MI_08#6&33932C53&0&0008' is no longer connected!
libusb: error [init_device] device '\\.\USB#VID_054C&PID_09AF&MI_04#6&33932C53&0&0004' is no longer connected!
libusb: error [init_device] device '\\.\USB#VID_054C&PID_09AF&MI_01#6&33932C53&0&0001' is no longer connected!
libusb: error [init_device] device '\\.\USB#VID_054C&PID_09AF&MI_06#6&33932C53&0&0006' is no longer connected!
libusb: error [init_device] device '\\.\USB#VID_054C&PID_09AF&MI_07#6&33932C53&0&0007' is no longer connected!
[2019-03-06 11:34:57.459]: PSVRClient - Successfully initialized PSVRClient
INFO [Renderer::init()] Initializing Renderer Context
libusb: error [init_device] device '\\.\USB#VID_054C&PID_09AF&MI_08#6&33932C53&0&0008' is no longer connected!
libusb: error [init_device] device '\\.\USB#VID_054C&PID_09AF&MI_04#6&33932C53&0&0004' is no longer connected!
libusb: error [init_device] device '\\.\USB#VID_054C&PID_09AF&MI_01#6&33932C53&0&0001' is no longer connected!
libusb: error [init_device] device '\\.\USB#VID_054C&PID_09AF&MI_06#6&33932C53&0&0006' is no longer connected!
libusb: error [init_device] device '\\.\USB#VID_054C&PID_09AF&MI_07#6&33932C53&0&0007' is no longer connected!
[2019-03-06 11:34:58.233]: TrackerUSBDeviceEnumerator - Skipping device (USB\VID_1415&PID_2000\b2_p1.2) - Operation not supported or unimplemented on this platform
[2019-03-06 11:34:58.239]: TrackerUSBDeviceEnumerator - Skipping device (USB\VID_1415&PID_2000\b2_p1.3) - Operation not supported or unimplemented on this platform
[2019-03-06 11:34:58.245]: TrackerUSBDeviceEnumerator - Skipping device (USB\VID_1415&PID_2000\b2_p1.3) - Operation not supported or unimplemented on this platform
[2019-03-06 11:34:58.250]: PS3EyeTracker::open - Opening PS3EyeTracker(USB\VID_1415&PID_2000\b2_p1.2, camera_index=0)
[2019-03-06 11:34:58.258]: USBAsyncRequestManager::openUSBDevice - Successfully opened device -1
[2019-03-06 11:34:58.435]: init_camera - PS3EYE Sensor ID: 7721
[2019-03-06 11:34:59.126]: startUSBBulkTransfer - request started
[2019-03-06 11:34:59.129]: WorkerThread::start - Starting worker thread: PS3EyeVideoFrameProcessor
[2019-03-06 11:34:59.140]: SharedVideoFrameBuffer::initialize() - Allocating video frame buffer:
[2019-03-06 11:35:11.46]: DeviceTypeManager::update_connected_devices - Device device_id 0 (PSEYE) opened
[2019-03-06 11:35:11.49]: PS3EyeTracker::open - Opening PS3EyeTracker(USB\VID_1415&PID_2000\b2_p1.3, camera_index=1)
[2019-03-06 11:35:11.56]: USBAsyncRequestManager::openUSBDevice - Successfully opened device -1
[2019-03-06 11:35:11.232]: init_camera - PS3EYE Sensor ID: 7721
[2019-03-06 11:35:11.926]: startUSBBulkTransfer - request started
[2019-03-06 11:35:11.929]: WorkerThread::start - Starting worker thread: PS3EyeVideoFrameProcessor
[2019-03-06 11:35:11.940]: SharedVideoFrameBuffer::initialize() - Allocating video frame buffer:
[2019-03-06 11:35:11.957]: DeviceTypeManager::update_connected_devices - Device device_id 1 (PSEYE) opened
[2019-03-06 11:35:11.990]: MorpheusHMD::open - Opening MorpheusHMD(USB\VID_054c&PID_09af).
[2019-03-06 11:35:11.993]: MorpheusHMD::open - Morpheus command interface is flagged as DISABLED.
[2019-03-06 11:35:11.996]: MorpheusHMD::open - Failed to open MorpheusHMD(USB\VID_054c&PID_09af)
[2019-03-06 11:35:11.998]: MorpheusHMD::close - MorpheusHMD already closed. Ignoring request.
[2019-03-06 11:35:12.1]: DeviceTypeManager::update_connected_devices - Device device_id 0 (USB\VID_054c&PID_09af) failed to open!

These lines might refer to the PSVR going by both having "VID_054C&PID_09AF" in them:

libusb: error [init_device] device '\\.\USB#VID_054C&PID_09AF&MI_08#6&33932C53&0&0008' is no longer connected!

PSVRToolbox is working as normal. DS4 is working fine, using Sony's built-in driver.

EDITED: Maybe "no longer connected" refers to it being a secondary monitor? Does the IR sensor have to have the screen turned on? Is there a "Run as Administrator" requirement? (PSVRToolbox seems to require that for some things. I find that to be a problem; if only because things break when not done so, but it otherwise seems to work fine. I'm not sure why it needs that.)

[HipsterSloth]

The PSVR is not appearing. It may be because there isn't the MorpheusHMDConfig.json file among the others.

The json file for all devices is created if one doesn't exist. I try to load it first and use default values if no config get's loaded. Then I save the config file back out if defaults changed. That happens here for the Morpheus:
https://github.com/HipsterSloth/PSVRTracker/blob/master/src/psvrservice/MorpheusHMD/MorpheusHMD.cpp#L544

MorpheusHMD::open is entered. I see a drivers folder that has WinUSB drivers. I assume these are identical to the ones I've installed for using PSVRToolbox.

Yeah those are the same WINUSB drivers that are generated by libusbk's "USB Inf Creator/Installer" Wizard (see https://sourceforge.net/projects/libusbk/). I'm pretty sure PSVRToolbox used them same driver creation wizard.

From your logs it looks like your USBManager is using libusb API instead of the WinUSB API. I forgot that libusb was set to the default API to use:

https://github.com/HipsterSloth/PSVRTracker/blob/master/src/psvrservice/Device/Manager/USBDeviceManager.cpp#L37

The USBManager can be set to use the WinUSB API instead if you either change that code OR set the "usb_api" to "winusb_api" in%appdata%/PSVRSERVICE/USBManagerConfig.json.

I was trying to support either USB api depending on what driver the user decided they wanted to use. Sorry for the confusion there.

I would like to see the SIXAXIS in the DS4 work too. Can it work over USB?

I'm honestly not sure if the DS4's controller input HID report is sent when connected via USB. I think I've only tried sending the bluetooth pairing address HID packet to the DS4. I haven't done much with DS4 support initial optical tracking work back in 2016. I made some videos back then talking in detail about all the stuff I was trying at the time in case you are curious:

Video 1 (8min): https://www.youtube.com/watch?v=ywxjFAQuxkQ
Video 2 (13min): https://www.youtube.com/watch?v=MPbegaB7cf0

Maybe "no longer connected" refers to it being a secondary monitor? Does the IR sensor have to have the screen turned on?

I think if you haven't successfully opened one of the USB interfaces on the Morpheus it will shut it self down after a few minutes? Or it might be that you have to put a post-it note over the head detection sensor in the HMD. I forget. It's been a while since I've tested this.

Is there a "Run as Administrator" requirement?

You should only need to run as an administrator when trying to pair a PSMove controller. That process involved poking the registry at the right time to force that controller to get through the window s bluetooth pairing process.

[m-7761]

The USBManager can be set to use the WinUSB API instead if you either change that code OR set the "usb_api" to "winusb_api" in%appdata%/PSVRSERVICE/USBManagerConfig.json.

This stuff absolutely must be automated. This Issue should remain open until it is. Or another Issue is filed.

I'm curious what happens, or if it's possible, if drivers are a mix of Libusb and Winusb?

I'm honestly not sure if the DS4's controller input HID report is sent when connected via USB.

I'm not 100% certain, but I've never noticed DS4Windows failing to support SIXAXIS motion controls when plugged in with just USB. I've never read anything to that effect. I think there is probably a way to read its state over USB. The DirectInput device only appears to output stick/trigger axes in the Control Panel.

---

Here is the new console output after switching to winusb_api:

[2019-03-07 15:34:24.179]: main - Starting PSVRService v0.1.0.0
[2019-03-07 15:34:24.181]: USBAsyncRequestManager::startup - Requested WinUSBApi
[2019-03-07 15:34:24.185]: USBAsyncRequestManager::startup - Creating WinUSBApi
[2019-03-07 15:34:24.188]: USBAsyncRequestManager::startup - Initialized USB API
[2019-03-07 15:34:24.191]: USBAsyncRequestManager::startup - Starting USB event thread
[2019-03-07 15:34:24.198]: DeviceManager::startup - Platform Hotplug API is ENABLED
[2019-03-07 15:34:24.442]: bluetooth_get_host_address - Failed to find a bluetooth radio
[2019-03-07 15:34:24.538]: PSVRClient - Successfully initialized PSVRClient
INFO [Renderer::init()] Initializing Renderer Context
[2019-03-07 15:34:25.120]: PS3EyeTracker::open - Opening PS3EyeTracker(\\?\usb#vid_1415&pid_2000&mi_00#7&17dfe650&0&0000#{4cff9941-d72f-4951-9291-03d8fc97fe30}, camera_index=0)
[2019-03-07 15:34:25.243]: init_camera - PS3EYE Sensor ID: 7721
[2019-03-07 15:34:25.286]: startUSBBulkTransfer - request started
[2019-03-07 15:34:25.289]: WorkerThread::start - Starting worker thread: PS3EyeVideoFrameProcessor
[2019-03-07 15:34:25.297]: SharedVideoFrameBuffer::initialize() - Allocating video frame buffer:
[2019-03-07 15:34:26.618]: DeviceTypeManager::update_connected_devices - Device device_id 0 (PSEYE) opened
[2019-03-07 15:34:26.623]: PS3EyeTracker::open - Opening PS3EyeTracker(\\?\usb#vid_1415&pid_2000&mi_00#7&2a9996f5&0&0000#{4cff9941-d72f-4951-9291-03d8fc97fe30}, camera_index=1)
[2019-03-07 15:34:26.745]: init_camera - PS3EYE Sensor ID: 7721
[2019-03-07 15:34:26.794]: startUSBBulkTransfer - request started
[2019-03-07 15:34:26.795]: WorkerThread::start - Starting worker thread: PS3EyeVideoFrameProcessor
[2019-03-07 15:34:26.807]: SharedVideoFrameBuffer::initialize() - Allocating video frame buffer:
[2019-03-07 15:34:26.823]: DeviceTypeManager::update_connected_devices - Device device_id 1 (PSEYE) opened
[2019-03-07 15:34:26.855]: MorpheusHMD::open - Opening MorpheusHMD(USB\VID_054c&PID_09af).
[2019-03-07 15:34:26.858]: MorpheusHMD::open - Morpheus command interface is flagged as DISABLED.
[2019-03-07 15:34:26.860]: MorpheusHMD::open - Failed to open MorpheusHMD(USB\VID_054c&PID_09af)
[2019-03-07 15:34:26.863]: MorpheusHMD::close - MorpheusHMD already closed. Ignoring request.
[2019-03-07 15:34:26.868]: DeviceTypeManager::update_connected_devices - Device device_id 0 (USB\VID_054c&PID_09af) failed to open!

The "is no longer connected" lines are no more. But it's still in the "Morpheus command interface is flagged as DISABLED." branch. You can see in the code link you provided that taking that branch does not save the Morpheus JSON file out to the user's settings.

Off-topic: It seems like I have the good fortune of finding a partner to develop something really big. I don't know if by the time we get around to a media event that we will have OpenXR or something to support all VR, but I still want to keep working on support for Sony's VR. I think they're likely to have the best VR for the foreseeable future anyway. We are going to be bringing the King's Field franchise back from the dead. It's the original 3D video game. It's kind of the poster child for VR. It's something I could not do by myself. But I think the coast is clear. This is why I'm so eager to figure this out. Plus for my own work, I'd rather not have to think about the head set drifting away. Even if my tracker-less solution is nice, it's never going to be perfect. I think having any degree of camera based tracking should work, since it provides an absolute reference.

[m-7761]

Update: I haven't (yet) run this code, but it looks pretty obvious that what is keeping the HMD from being detected is the following constructor:

    MorpheusHMDConfig(const std::string &fnamebase = "MorpheusHMDConfig")
        : PSVRConfig(fnamebase)
		, is_valid(false)
		, version(CONFIG_VERSION)
		, disable_command_interface(true)

I assume this is by design, so to force use of a virtual HMD? But I want to explore use of the HMD's sensors, and develop a server if one is not there.

I also see a comment in the translation-unit that says:

		// Open the command interface using libusb.
		// NOTE: Ideally we would use one usb library for both interfaces, but there are some complications.
		// A) The command interface uses the bulk transfer endpoint and HIDApi doesn't support that endpoint.
		// B) In Windows, libusb doesn't handle a high frequency of requests coming from two different threads well.
		// In this case, PS3EyeDriver is constantly sending bulk transfer requests in its own thread to get video frames.
		// If we started sending control transfer requests for the sensor data in the main thread at the same time
		// it can lead to a crash. It shouldn't, but this was a problem previously setting video feed properties
		// from the color config tool while a video feed was running.
		if (!cfg.disable_command_interface)
		{
			morpheus_open_usb_device(USBContext);
		}
		else
		{
			PSVR_LOG_WARNING("MorpheusHMD::open") << "Morpheus command interface is flagged as DISABLED.";
		}

This kind of sounds like it wants "libusb" but the drivers are WinUSB.

I'm just looking for (RFC) ideas about what to do with this constructor, and if there is a WinUSB conflict here. What if the "USB Manager" is set to use winusb_api?

I'm going to explore these things for myself. But prefer to have advice.

EDITED: It also occurs to me that this code considers the "command_interface" separate from the sensor. But the check for this state seems to preclude writing a configuration file. I don't know if "morpheus_open_usb_device" corresponds to "getIsOpen" but if so, there's no way to open the device without the command-interface request. I don't know if there is a backdoor for sensors. But it makes it so no HMD appears on the PSVRConfigTool, and prints disconcerting output.

[HipsterSloth]

That comment is a bit confusing and old (This code was copied from in-progress PSVR work in PSMoveService). It is true that libusb has the threading problems mentioned, but that is handled now in the usbmanager. All usb requests are managed on single worker thread with a message queue.

The intent of the disable flag is separate from any usbapi issue. It was to allow to this tool to access the sensor data interface but let another tool (PSVRToolbox) use the command interface to control the lights. I also tested with the disable flag turned off. Honestly I think this flag can be removed at this point.

As for this winusb/libusb setting I just set it to match the psvr driver I was using for the headset. That said, there is no reason that there has to be only one usbapi active. In theory usbmanager could have both apis available. Libusb was just the api I got working first, then started working on winusb support. I never got to finish the cleanup work to support both at the same time.

As you have noticed over the last week, there are a lot of sharp corners to get caught on right now. I had to drop work on this project 6 months ago to address a bunch of user issues with PSMoveSteamVRBridge, which left a lot of stuff unfinished.

[m-7761]

I will change the default to winusb_api if you haven't already/I don't forget. I have some weirdness to report about the HMD enumeration:

Basically my system enumerates 3 devices for the HMD that all use 8 for their interface-number:

"\\\\?\\hid#vid_054c&pid_09af&mi_08&col01#7&318e0f89&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"

(EDITED: I see this GUID requests the device driver.)

This the next. Everything looks the same, except col02. The third/final is col03.

"\\\\?\\hid#vid_054c&pid_09af&mi_08&col02#7&318e0f89&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}"

Device Manager shows several devices (usually but not always marked as VR) with these IDs, but I can't find mi_08 among them. And I have no idea why hid_enumerate (hid.c) would enumerate these instead of the others.

The set is on. Finger over IR sensor lights up its screen. I'm sure PSVRToolbox works. Maybe you've seen this before?

EDITED: I'm not sure this is the only place that collects devices. But in open it does USBContext->sensor_device_path = pEnum->get_hid_hmd_enumerator()->get_interface_path(MORPHEUS_SENSOR_INTERFACE); which looks in that list, and only finds those 3. Which don't match.

[m-7761]

Note, the PSVRFramework code looks like this:

var ndev = UsbDevice.AllDevices.Where(d => d.Vid == 0x54C && d.Pid == 0x09AF && d.SymbolicName.ToLower().Contains("mi_05")).FirstOrDefault();

It's very straightforward. I suspect hid_enumerate is not using the APIs correctly. I can't think of why it would omit matches if not.

[m-7761]

Man I hate to keep returning to this Issues tracker! The GUID is GUID_DEVINTERFACE_HID. While poking around I happened across this:

https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/finding-and-opening-a-hid-collection
I don't know. It's probably nothing, but "collection" looks a lot like col01, col02, col03 but doesn't really explain _mi08. (EDITED: I think this is something else on further reading. Still can't find _mi08 in Device Manager.)

I wonder if there's something unusual about my system. As far as I know it's not like Trinus PSVR (I think it's installed) or PSVRToolbox would change things simply by being installed.

P.S. I tried to use GUID_DEVINTERFACE_USB_DEVICE on a lark. It didn't enumerate anything. It seemed closer to "UsbDevice.AllDevices" and is among the valid GUID for SetupDiGetClassDevsA. I don't really understand what "HID" is, or how it differs from USB. It's human-interface I think, but I know also it's part of the RawInput API family. Shouldn't we be using USB?

[HipsterSloth]

Oh! Sorry, I was mistaken earlier in saying that you should switch over using the WinUSB setting. I forgot that libusb can use both the libusb-0.sys and winusb.sys kernel drivers. If you set the USB manager to use the WinUSB api then only devices that have the winusb.sys kernel drivers will work. I was implementing the two APIs because only the WinUSB API supports isochronous USB transfers, but that's only needed for the microphone stream interface, and that isn't supported yet (and probably won't be anytime soon).

You can verify which usb driver each usb interface has installed using usbdeview:
https://www.nirsoft.net/utils/usbdeview-x64.zip

On my machine you can see that interface 4 has Hidusb.sys (installed by windows by default) and interface 5 has WinUSB.sys installed on it (Installed by drivers\WinUSB\PS_VR_Control_Interface_5\InstallDriver.exe)

Device Manager shows several devices (usually but not always marked as VR) with these IDs, but I can't find mi_08 among them. And I have no idea why hid_enumerate (hid.c) would enumerate these instead of the others.

I also missed that you were only getting interface 8 back. That is also a PSVR HID interface (PS VR Control2 according to this), but not HID interface 4 (PS VR Sensor). This implies to me that you don't have HidUSB,sys installed in that interface. You can verify this with usbdeview. If some other driver is bound then hidapi won't enumerate that interface.

https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/finding-and-opening-a-hid-collection
I don't know. It's probably nothing, but "collection" looks a lot like col01, col02, col03 but doesn't really explain _mi08. (EDITED: I think this is something else on further reading. Still can't find _mi08 in Device Manager.)

Thanks for that reference. I had honestly not really understood what the collection portion of the HID interface was. The HID (Human Interface Device) API is a layer on top of USB (on top of Interrupt transfers I believe), that is used to send and receive "HID Reports". The sensor data we get in interface 4 is one type of report. It's up to the hardware to decide how it wan't to group up the reports into a collection, where a collection has a CAPS structure that defines what kind of reports it has.

As you noticed, the get_interface_path(MORPHEUS_SENSOR_INTERFACE) line is scanning the list of hid collections return on all interfaces of a usb device. It's lazily returning the first collection it finds for a given interface. It just so happens that the the first collection on interface 4 is the one we want.

[m-7761]

I will (of course) mess around with this. I'm available to work on this stuff full-time, so I hope you will also try to meet me half way and try to pull things together in the meantime. Going by your videos (above) you're clearly invested in this, so I imagine you'd like to get it off the ground too!

FWIW I've, of course, tried with libusb_api also. And I've installed the 4 driver from your files. I did not install 5 because it looked identical to the one installed by PSVRFramework's files. And because 4 didn't work. I think whatever PSVRFramework is doing we should be looking at... because it works reliably. It works on my system, while PSVRTracker does not. I'm not sure what else I should have to install (HidUSB,sys?) but I will dig into it. I did look at the USB (.net) library it uses yesterday.

I'm thinking of no longer throwing myself at this problem near-exclusively everyday until all of the devices are detected/figured out... so I'm not just reporting problems day-in-day-out! The last few days with it have not felt like productive ones. I'm also more than a little concerned about performance (CPU) and am beginning to wonder if a desktop PC just cannot host cameras reasonably. The code running on my PC is nowhere close to what's reasonable allotment of resources to a peripheral. My workstation has a much better CPU than I would ever require of a game to run (for building software) so it's a nonstarter if it cannot do the tracking even without a game using the CPU at the same time.

[HipsterSloth]

And I've installed the 4 driver from your files.

I think this is the problem. When you install the driver for interface 4 that replaced the default HidUSB.sys driver installed with WinUSB.sys. Once WinUSB is installed on that interface I can't use hidapi to read data from that device anymore. You can actually communicate on a HID interface using the WinUSB protocol directly, which is what PSVRFramework is doing.

I think I originally was using the WinUSB for interface 4 (since this code as originally adapted from PSVRFramework), and then switched over to HIDApi since you have to go through more layers to get to the OS function calls with when using libusb (hidapi is a very thin wrapper around the windows HID calls). I wouldn't care about routing through libusb, normally but the sensor data comes in at about 1000hz so I didn't want to add anymore overhead.

TL;DR - If you want to get interface 4 working now you should uninstall the driver on interface 4 in windows device manager:

After you do, you'll want to unplug and re-plugin the usb connection. It should fallback to HidUSB.sys on interface 4. You can verify this with usbdeview.

On my end, I'm going to do two things:

1. Remove the driver for interface 4
2. Add support for WinUsb api back in as a fallback. That way you someone who wants to use PSVRFramework still can still do so without having to uninstall the driver. This will actually let me A/B test the perf difference I'm claiming will be an issue between hidapi and libusb.

I'm also more than a little concerned about performance (CPU) and am beginning to wonder if a desktop PC just cannot host cameras reasonably.

A reasonable concern. After this usb change, I'm going to see how much the blue-only channel filtering + GPU accelerated color filtering helps. Your target user experience is two PS3 eye cameras correct?

[m-7761]

Okay, I was actually composing a reply as you posted. I understood you, I just had to make time to look into it. My thoughts are below. Maybe there's something interesting in them, I don't know.

Your plan sounds good. I can implement the same functionality as PSVRToolbox. I can implement the UDP server. And hopefully we can come up with a C++ service with the same feature set (plus more) as the dead PSVRToolbox. My only reservation is the UI using SDL versus the more user-friendly one provided by PSVRToolbox ... and the fact that this project is really just an arm of PSMoveService, and will ultimately go the way of the dodo bird itself!

Maybe we can negotiate something through email. I have to develop a configurator style tool for my game-development software, that will ultimately be provided for configuring all of these peripherals. Whether it hosts the service or not. So, I don't mind if there is a need for a third, front-end, project. I need to provide one program that also includes game settings. There could be a base program that can serve as a front-end, that third-party projects can extend. That could use SDL though I have no background with it. wxWidgets maybe. Not QT. Definitely not C#. (EDITED: I'm actually more incline to use a flat interface, like RetroArch's PS3 user-interface. I actually approached them the other day to see if their UI could be made into a library. They thought it was too messy/unusable.)

Your target user experience is two PS3 eye cameras correct?

This is what I would recommend, if it can have a small CPU footprint. Even one PSEye if it can be made to work reasonably. I'm personally interested in not drifting. Some head movement is okay, but I am not trying to achieve an amusement park style standing experience. I'm really interested in VR on the lowest common denominator budget. PS3Eye is the more affordable option. As long as the cameras remain available.

-------COPY OF MY ORIGINAL REPLY FOLLOWS------

I also missed that you were only getting interface 8 back. That is also a PSVR HID interface (PS VR Control2 according to this), but not HID interface 4 (PS VR Sensor). This implies to me that you don't have HidUSB,sys installed in that interface. You can verify this with usbdeview. If some other driver is bound then hidapi won't enumerate that interface.

Okay... so it seems to me that there needs to be some work done here, since what your saying is to NOT install PSVRTracker\drivers\WinUSB\PS_VR_Sensor_Interface_4\InstallDriver.exe from your own project's files. You can see how that's misleading. Plus as-far-as-I-know PSVRToolbox needs this custom driver to be installed to function.

Maybe it doesn't, but its project also recommends installing a libusb/WinUSB driver over Interface 4. So either PSVRTracker needs to work with that driver, or it needs to provide the functionality of PSVRToolbox (I'm all for the latter, but know it will be uphill battle. I'm on board to implement it if you can get the USB channel opened up for me to program against. I have no experience there)

[m-7761]

Following up: The HMD situation has improved and seems resolved, however I think DS4 is not recognized over BT and should have USB support added.