* `m_usb_manager.update()`
* `m_device_manager.update()`

Process any async results from the USB transfer thread.

DeviceManager::update() calls each specific manager's .poll(), .updateStateAndPredict(), and .publish() in a specific order. These methods are described in more detail in the sections below about the Device<Type>Managers.

During the application loop we call m_device_manager.update(). We glossed over this above but we will go into more detail here. This function has the following contents.

    m_tracker_manager.poll(); // Update tracker count and poll video frames
    m_hmd_manager.poll(); // Update HMD count and poll position/orientation state

    m_tracker_manager.updateStateAndPredict(); // Get controller colors and update tracking blob positions/predictions
    m_hmd_manager.updateStateAndPredict(); // Get the pose + prediction for HMD

    m_tracker_manager.publish(); // publish tracker state to any listening clients (probably only used by ConfigTool)
    m_hmd_manager.publish(); // publish hmd state to any listening clients (probably only used by ConfigTool)

Each m__manager is an instance of the respective DeviceManager, which is a child of DeviceTypeManager.

Each m__manager.poll() is handled by the parent class method.

This calls poll_devices() and update_connected_devices() if sufficient time has elapsed (poll_interval and reconnect_interval). poll_devices() simply iterates through each device in m_devices and calls its poll(). Each m_device is a pointer to a ServerDeviceView (see below). update_connected_devices() adds/removes devices to the m_devices list; this is device-type-specific.

This will derive a state from the data and update a model that allows prediction. This is just a wrapper around the (ServerDeviceViewPtr) device->updateStateAndPredict() which is purely virtual and implemented by the device-specific views.

1. Allocate a DeviceEnumerator (specific enumerator allocated by derived DeviceTypeManager)
2. Process device shuffling or attachments
   • See if any devices shuffled order OR if any new devices were attached.
   • Migrate open devices to a new temp list in the order that they appear in the device enumerator.
3. Process device removal
   • Close any remaining open controllers not listed in the device enumerator.
   • Copy over any closed controllers to the temp.
4. Copy the temp controller list back over top the original list.
   • send_device_list_changed_notification() is device_type-agnostic.
5. Free the device enumerator
6. Send notification to connected clients if the device list changed

This simply iterates through each device in m_devices and calls its publish().

Let's look at each derived DeviceTypeManager.

Derived DeviceTypeManager that manages all connected camera types. Creates a TrackerDeviceEnumerator when scanning for connected camera. Specific tracker views can be accessed from this manager. Controller connections can't be updated while a controller pairing request is running. Currently the only supported tracker types are the PS4CameraTracker and the VirtualStereoTracker.

Derived DeviceTypeManager that manages all connected HMD types. Creates a HMDDeviceEnumerator when scanning for connected HMDs. Specific tracker views can be accessed from this manager. Currently the only supported tracker types are the MorpheusHMD and VirtualHMD.

Next we will look at the device poll() and publish() methods of of the devices which are called during DeviceTypeManager::poll_devices() and DeviceTypeManager::publish(), respectively. These are called on the upcast form of the device so we call the generic ServerDeviceView parent class methods.

This gets the (upcast) *IDeviceInterface with getDevice() then calls its ->poll() method. If polling was successful, then we mark the device as having an unpublished state. IDeviceInterface::poll() is virtual and must be implemented by each specific Interface (see below for details of the devices).

A wrapper around ServerDeviceView::publish_device_data_frame(). This is device specific and is implemented by the child class. It will tell the instance of the ServerRequestHandler to publish_<type>_data_frame with a type-specific callback (e.g., &ServerControllerView::generate_controller_data_frame_for_stream) that is sent to the client API.

Let's look at the device-specific implementations, including updateStateAndPredict() called during DeviceTypeManager::updateStateAndPredict().

Currently does nothing.

TODO: Implement ServerRequestHandler::get_instance()->publish_tracker_data_frame(...). This will call ServerNetworkManager::get_instance()->send_tracker_data_frame(connection_id, data_frame); TODO: TrackerDataFramePtr.

TODO: Implement ServerNetworkManager::send_tracker_data_frame. Adds the frame to the write queue and starts the UDP write. Does this have to be device-type-specific? What about just overloading using the data_frame argument type?

TODO: Implement ServerTrackerView::generate_tracker_data_frame_for_stream

TODO: Implement PSMoveTracker in PSMoveTracker.cpp, including poll().

Currently does nothing.

TODO: Implement ServerRequestHandler::get_instance()->publish_tracker_data_frame(...). This will call ServerNetworkManager::get_instance()->send_hmd_data_frame(connection_id, data_frame);

TODO: Implement ServerNetworkManager::send_hmd_data_frame.

TODO: Implement ServerTrackerView::generate_hmd_data_frame_for_stream

TODO: Implement PSMoveHMD in PSMoveHMD.cpp, including poll().