To avoid having to break up images into small chunks.

Current approach

Fixed-size circular queue of buffers, with sequence numbers. If a recipient wants to keep an image, it needs to copy it out. (Alternately, could use semaphores per-buffer to keep images around.)

Previous approach

Looking at a reference-counted, publish-subscribe model, with a per-subscriber message queue that can hold a reference-counting smart pointer to image buffers.

Subscriber registry:

• Subscriber opens subscriber registry, adds self with unique ID.
• Subscriber opens message buffer keyed by ID.
• When subscriber exits, removes self from registry.

Right now, have an implementation of the subscriber registry using shared memory, but that doesn't correctly handle apps closing "badly" - something like a pipe would be better.

General flow - Publisher

• On data send: publisher allocates block of the right size/alignment, managed by a smart pointer, and puts data in it, adding a ref. (ref count = 1)
• Publisher get subscriber list and puts a message in each subscriber's buffer, with each owning a ref. (ref count = 1 + subscribercount)
• Publisher releases its ref to that data. (ref count = 1 + subscribercount)

General flow - Subscriber

• When subscriber updates, checks for messages in its buffer.
• If one found, the reference to the data block is moved to the message handler and the message is handled (maintaining a proper reference count)

Detail/Complication

To maintain a proper reference count on the shared memory image blocks, we need each pending message to hold a reference (smart pointer) to the image block it corresponds to. However, then, we must make sure that each message is serviced somehow - either by an active application, or by some cleanup when that application exits - otherwise we'll exhaust our shared memory segment with images that nobody is really looking at.

Should use the tree data structure and create listeners only for the devices that are there and requested via an interface. Replaces a chunk of the current VRPNContext code.

Sample case is the YEI tracker: we have a VID/PID, want to look up the port so this can be autodetected instead of manually configured.

Per @yboger it comes up for both the server and client. This should not be.

To allow resetting which direction is forward. May or may not be a client API - current work involves a separate application that could become a button in a GUI settings panel.

The class template osvr::client::traits::ReportTypeWrapper can be replaced with a simple boost::mpl::identity

No need to have it separate.

Right now the multiserver just passes things blindly on to the VRPN server, which will try and fail to talk to a port. We should be able to at least screen to see if the port exists, returning a failure if it doesn't, to stop the scrolling of cannot write to serial.

We don't want plugins just spewing to stdout by default, as they're doing now. We want something we could route into a GUI at some point.

Free typesafety for C++ users.

We should store those together so you only need the interface object. This will break API and ABI, so the sooner the better.

Updated schema location (with an updated schema) is https://github.com/OSVR/OSVR-JSON-Schemas

This would require changing the data storage technique so that devices could register themselves and provide an object (pointer and deleter), so we know what to call when they fail.

These should have centralized definitions. Some already do (see osvr::common::routing_keys)

Right now it refers to vrpn_print_messages obliquely - not clear what that is (an app) or why you'd use it (if you are testing a new message type that you don't have a client for yet).

Should include instructions on testing with the Tracker Viewer and vrpn_print_devices instead (or rather, more prominently anyway)

The repo is https://github.com/OSVR/discount

Example integration is here: https://github.com/OSVR/distortionizer/blob/master/CMakeLists.txt#L44

Use to bundle some HTML readme/intro-type file with the binary distributions.

cc @yboger - the current default config file is for the YEI version of the HDK. This trips up both users of the Bosch version of the HDK, as well as those trying to use the Oculus, since the YEI driver spams the screen with error messages in trying to talk to a non-existent serial port. (see #11 )

Ideally, and eventually, the default config file will be empty, loading all plugins by default and auto-detecting devices with auto-selected routes. The question is what to do in the meantime. Do we:

1. Change the default config file to be the HDK Bosch one?
2. Have no default config file, providing an error message saying "you have to pick a config"?

Running OSVR_calibrate multiple times creates a history of the calibration data instead of overwriting it.

For instance:

{
"plugins" : [ "org_opengoggles_bundled_Multiserver" ],
"routes" : [
{
"destination" : "/me/head",
"source" : {
"child" : {
"child" : {
"child" : {
"sensor" : 0,
"tracker" : "/org_opengoggles_bundled_Multiserver/OSVRHackerDevKit0"
},
"rotate" : {
"axis" : [ -0.7397290853882557, 0.6728198380315612, 0.01069325870997396 ],
"radians" : 3.238542030975339
}
},
"rotate" : {
"axis" : [ -0.1116648429726947, -0.3359507666652563, 0.9352368925683535 ],
"radians" : 0.962467929996628
}
},
"rotate" : {
"axis" : [ 0.1937018319634984, 0.04169637136441404, -0.980173970736331 ],
"radians" : 0.4892860528189486
}
}
}
]
}

I haven't personally used it, but I know that a number of (non-game-engine) apps use GLM as their math library, so an interop header akin to https://github.com/OSVR/OSVR-Core/blob/master/inc/osvr/Util/EigenInterop.h would be useful in those cases.

Per a presentation I read re: Ubisoft's dev. of games in C++ , they don't allow boost in their main tree, and I'm sure they're not the only ones. The main reason we're using Boost in the clientkit bindings is for relatively simple things (shared_ptr, etc) that we could get if the user agreed to a higher C++ standard (Not sure if TR1 suffices or if C++11 is needed, offhand)

(presentation is here: https://github.com/CppCon/CppCon2014/blob/master/Presentations/C%2B%2B%20in%20Huge%20AAA%20Games/C%2B%2B%20in%20Huge%20AAA%20Games%20-%20Nicolas%20Fleury%20-%20CppCon%202014.pdf I just read the slides, didn't watch the video)

http://eigen.tuxfamily.org/index.php?title=ChangeLog#Eigen_3.2.4

The descriptors are currently over in https://github.com/OSVR/OSVR-Unity/tree/master/OSVR-Unity/Assets/OSVRUnity/Displays

Server should hold a path tree structure and be able to send state/updates to clients, prompting traversal.

Leaving links as notes.

https://wiki.debian.org/ArmEabiFixes#Floating_point_format_has_changed

No need to have this separate, since both client and server will need it.

This is for plugins that are transferring large data (like images) and whose data might never leave the server. The basic design is that the plugin will supply a deep copy of the data along with a destruction method and a serialization method. Local subscribers will get access to the copy, if any remote clients for it exist serialization is performed, then finally the copy is destroyed.

The file is here: we can and should move it in: https://github.com/OSVR/OSVR-Tracker-Viewer/blob/master/OSGMathInterop.h

Users shouldn't have to know to enter \\.\COM13 instead of COM13. Need to figure out what requirement always prepending this imposes (NT-based Windows maybe?), determine if it's acceptable, and make this automatic.

Knowledge base should be updated when this is done.

Right now only MSVC lets you just get away with C++11 without asking for it. We should ask for it elsewhere. Main usage right now is for unique_ptr which can't be done without it - though we could sub in shared_ptr at the cost of some overhead.

The descriptors are currently over in https://github.com/OSVR/OSVR-Unity/tree/master/OSVR-Unity/Assets/OSVRUnity/Displays

A GUI console for the server, with a list of loaded plugins and running devices.

The way we do imported targets requires 3.0 or newer. Not sure what CMake policies we'd change by setting the min required in the script to 3.0, but we could fail on older than 3.0, and at least put it in the docs.

Right now it just complains without explaining what to do (at least with the json-schemas submodule) to fix it.

There's a lot of pieces to the full OSVR platform. Would be nice if we could get a global view of issues, milestones, etc. across multiple repos.

Some candidates I ran across in preliminary googling:

• https://waffle.io/
• https://github.com/rauhryan/huboard & https://huboard.com/

cc @yboger

vrpn_Endpoint::send_pending_reports():  select() failed.
Windows Sockets Error (10093):  Either the application has not called WSAStartup, or WSAStartup failed. .
vrpn_Connection_IP::send_pending_reports:  Closing failed endpoint.
Connection was deleted while 1 references still remain.

@russell-taylor - I was wondering if you've seen something like this before. Should we have an extra WSAStartup/its opposite pair in the client context open/close? This happens even on a "tidy" shutdown (with a ctrl-c handler installed to tell it to stop looping). My first instinct is that either a: the error state isn't being cleared before each operation and some error check is wrong, or b: there's an extra WSAShutdown (or whatever the opposite is called, I can't recall off the top of my head) in VRPN that isn't matched by a startup.

We can go based off of the osvr.github.io styling. Should include a link back to that page and to the repo page.

In the Async plugin we have:

ogvrPluginRegisterDataWithDeleteCallback(
ctx, &generic_deleter, static_cast<void *>(myAsync));

immediately after creating the data. Same on sync. Shouldn't we have a way to combine the creation and the registration of the deletion?

It searches the current directory for osvr_server_config.json, and the sample is bundled in the bin directory assuming you'll just run the executable where it is, or change directory to that path in your command prompt.

Some items, particular in Connection, are becoming redundant with code in Common, and attempt to do interface hiding that we end up having to bypass anyway, making code more complex.

via @russell-taylor - we erroneously require boost to be installed in the same place, same version, when using an installed build of OSVR and the C++ header-only wrappers. Since they're header-only, there's no ABI issue, so we don't actually care what version gets used.

Particularly including how to set CMAKE_PREFIX_PATH and/or ogvr_DIR. Per observations by @sergiog-github

For runtime reset of heading. In progress.