Cross-platform support

[thaytan]

In the interests of iterating fast, I've probably used posix or GNU specific API in places. Getting things running on Windows and other unixes needs testing.

UVC camera access is done directly through libusb, which should work cross-platform but again - needs testing.

[TheOnlyJoey]

Currently libusb is not really meant to be used directly (driver only use it through hidapi-libusb), and having a hard dependency against libusb would mean losing support for hidraw only.

A solution would be looking into a first draft implementation of libconvergence to replace hidapi/libuvc/libusb. Another would be platform testing to see how big of a issue this would be for short term.

[thaytan]

The USB interfaces we need to talk to are not HID interfaces, so hidapi is not an option. I'm not sure that it excludes hidapi-hidraw mode - that will still be used for talking to the HMD, and libusb will be used to talk directly to the (completely separate) camera sensor.

[mironovil]

Hello. I am linux user. I have oculus rift CV1 with oculus touch. Can I help you with something?

[thaytan]

Hi! This issue is about making sure that the new code (particularly the USB camera sensor access) is portable to Windows and MacOS - less so with Linux, which is where I'm doing my development.

Take a look at the other issues I've filed and see if anything looks approachable for you. Otherwise, just testing things and reporting your experience is useful too. Don't expect too much yet though - it's early development still!

I'm currently working on the https://github.com/thaytan/OpenHMD/tree/rift-correspondence-search but I think I'll do some consolidation of all the work so far to a new clean development branch soon.

[sid-cypher]

I've tried building rift-kalman-filter 678f7a1 on Windows 7 using VS2019 last weekend.

Following the Readme file, first I tried Meson, but that failed - latest Meson installer requires Win10. So I decided to simply used the CMake bundled in Visual Studio 2019 Desktop C++ development package.

After spending some hours gathering the dependency puzzle pieces and putting them together, I arrived at following configuration: (all paths for this project are in D:/dev)

Deps:

• hidapi-0.7.0
• hidapi-externals
• libusb-1.0.24
• opencv-4.5.2
• OpenHMD-rift-kalman-filter
• pkg-config-lite-0.28-1
• vs2019

Missing libusb-1.0.pc file:

prefix=D:/dev/libusb-1.0.24
libdir=${prefix}/VS2019/MS64/dll
includedir=${prefix}/include/libusb-1.0

Name: libusb
Description: libusb 1.0 Windows binary snapshot
Version: 1.0.0
Requires: 
Conflicts:
Libs: -L${libdir} -lusb-1.0
Cflags: -I${includedir}

Config:

D:\dev\OpenHMD-rift-kalman-filter\build> cmake -DCMAKE_INSTALL_PREFIX:PATH=D:/dev/openhmd -DOPENHMD_DRIVER_ANDROID:BOOL=OFF -DOPENHMD_DRIVER_DEEPOON:BOOL=OFF -DOPENHMD_DRIVER_EXTERNAL:BOOL=ON -DOPENHMD_DRIVER_HTC_VIVE:BOOL=OFF -DOPENHMD_DRIVER_NOLO:BOOL=OFF -DOPENHMD_DRIVER_OCULUS_RIFT:BOOL=ON -DOPENHMD_DRIVER_OCULUS_RIFT_S:BOOL=ON -DOPENHMD_DRIVER_PSVR:BOOL=OFF -DOPENHMD_DRIVER_VRTEK:BOOL=OFF -DOPENHMD_DRIVER_WMR:BOOL=OFF -DOPENHMD_DRIVER_XGVR:BOOL=OFF -DOPENHMD_EXAMPLE_SDL:BOOL=OFF -DOPENHMD_EXAMPLE_SIMPLE:BOOL=ON -DOpenCV_DIR:PATH=D:\dev\opencv-4.5.2\build\cmake -DHIDAPI_LIBRARY:PATH=D:\dev\hidapi-0.7.0\windows\Release\hidapi.dll -DHIDAPI_INCLUDE_DIR:PATH=D:\dev\hidapi-0.7.0\hidapi -DPKG_CONFIG_PATH=D:\dev\pkg-config-path -DPKG_CONFIG_EXECUTABLE:PATH=D:\dev\pkg-config-lite-0.28-1\bin\pkg-config.exe -G "Visual Studio 16 2019" ..

-- Selecting Windows SDK version 10.0.19041.0 to target Windows 6.1.7601.
-- The C compiler identification is MSVC 19.28.29914.0
-- The CXX compiler identification is MSVC 19.28.29914.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: D:/dev/vs2019/VC/Tools/MSVC/14.28.29910/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: D:/dev/vs2019/VC/Tools/MSVC/14.28.29910/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: D:/dev/pkg-config-lite-0.28-1/bin/pkg-config.exe (found version "0.28")
-- Checking for module 'libusb-1.0'
--   Found libusb-1.0, version 1.0.0
-- Found OpenCV: D:/dev/opencv-4.5.2/build (found version "4.5.2")
-- Found HIDAPI: D:/dev/hidapi-0.7.0/windows/Release/hidapi.dll
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:
    PKG_CONFIG_PATH
-- Build files have been written to: D:/dev/OpenHMD-rift-kalman-filter/build

Build:

Build started...
1>------ Build started: Project: openhmd, Configuration: Debug x64 ------
1>rift-sensor-uvc.c
1>D:\dev\OpenHMD-rift-kalman-filter\src\drv_oculus_rift\rift-sensor-uvc.c(1,10): fatal error C1083: Cannot open include file: 'asm/byteorder.h': No such file or directory
1>Generating Code...
1>Done building project "openhmd.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

Now 'asm/byteorder.h' looks like a kernel header to me, so that's not cross-platform enough.

[thaytan]

I pushed a couple of fixes for MSVC (like the byteorder.h include), but it's not enough to get things building. The UVC driver directly uses the posix monotonic clock - an API that Windows doesn't have. It will need to go through the OpenHMD compat call, but that made me realise that there's probably more wrong with the timing handling on Windows around that.

[sid-cypher]

Apologies if I'm ignorantly bringing up wrong/irrelevant stuff, but a cursory search gives examples like profileapi.h QueryPerformanceCounter for the monotonic clock thing, and there's stuff like cross-platform libuvc, too.

Don't know when I'll get to figuring out OpenHMD code, but I do love the idea of not only having free software drivers, but knowing them enough to play around with changes, too.

[thaytan]

OpenHMD has wrapper function for getting monotonic clock time already, I just didn't use it in that spot because it was awkward.

This simple UVC driver is basically doing what libuvc does, but allows me to maintain a queue of zero-copy framebuffers, and to talk directly to the USB device to send the radio commands that makes the cameras listen for exposure triggers from the headset.