Autodetect All the Things!

[godbyk]

I'm proposing a policy for OSVR wherein OSVR attempts to autodetect as much as possible and require as minimal user-configuration as possible while still providing the maximum user experience.

Currently, OSVR is rife with configuration files. Any time a new major feature is added, it's accompanied by one or more configuration files or subsets thereof. This is causing a huge headache for the end-users of OSVR—developers and gamers alike.

Stuffing settings, options, and data into configuration files is usually done as a quick workaround during development because the developer (a) doesn't know what the best default is; (b) hasn't yet written code to autodetect the best values; or (c) is unable to provide the data in any other way via the current API. Only rarely is it the case that the values cannot be autodetected and must be provided via a user-specified configuration file.

Let's examine what information is in the current configuration files and how we can autodetect it instead.

Server configuration

Automatically loaded plugins

Most of the plugin-specific configuration parameters should have sane defaults. The configuration file should only be used to override those defaults at the user's discretion.

Manually loaded plugins

Manually loaded plugins must still be specified in the configuration file, of course. We should strive to keep their number low, however.

Aliases

Aliases are generally provided by plugins. The only aliases required to be provided by end users are the custom aliases the end user wishes to create.

Display descriptors

Display descriptors should be provided by OSVR plugins that detect those HMDs. Many times the plugins can provide device-specific descriptors that are more accurate than the general configuration files that exist today. For example, the OSVR-OculusRift plugin should provide its display descriptor via the PluginKit API instead of via a configuration file.

RenderManager configurations

Much of the RenderManager configuration can be autodetected. The display index, rotation, and color depth; the window size and position; and the availability of direct mode are all autodetectable. The other parameters should have sane (and performant) defaults. The end user should only need to specify values when they'd like to override the defaults.

Related work

Triggering hardware detection

Plugins are asked to check for their associated hardware when 'hardware detection' is triggered. Currently, hardware detection is only triggered when a new client connects to the server. This means that if hardware is added or removed from the system, the server is completely unaware of it because the plugins haven't been asked to look for it.

OSVR (or a special plugin) should monitor for hardware changes and trigger hardware detection any time a device is added or removed. This would allow users to hot-plug devices without restarting the client or server.

Detecting display configuration

A common problem users are encountering is that the default configuration assumes that the user's primary display has a resolution of 1920×1080 and sits directly to the left of the HMD display. Any deviations from this configuration require the user to modify the OSVR server configuration file before their SteamVR games will work properly without custom configuration.

As mentioned above, RenderManager (or another component that can provide the information to RenderManager) should autodetect the display configuration and the HMD's position within it so that, for example, the information can be provided to the SteamVR client.

Requirements

To implement this Autodetect All the Things policy, we need to add some new API calls:

1. Add a method to the PluginKit API so that plugins can provide their own display descriptor programmatically (issue Display interface in plugins #35).
2. Write plugins to detect Sensics and OSVR HMDs and provide their display descriptors.
3. Add functionality to RenderManager to autodetect more of its configuration (especially the display configuration—the positions and resolutions of attached displays).
4. Modify osvr_server so it may run without a configuration at all (issue Configuration-free server #228 and PR osvr_server support for cmdline options and blank config generation (resolves #228) #293) or by detecting the best configuration file (PR Automatically find config data or load default #265).
5. Add a method to the PluginKit API so that a plugin can trigger hardware detection (issue Interface for plugins to trigger hardware detect #155 and PR Added API to PluginKit so plugins can trigger hardware detection. #404).

Request for comments

Please leave comments on this proposal below. Feel free to expand the proposal with information on other things that may be autodetected. Link to related issues and pull requests when you find them.