Input Subsystem#
Abstract classes#
The base input classes are FGEventInput (a
subsystem), which creates and owns a number of devices
(subclasses of FGInputDevice). Using some I/O source, an
implementation generates events, which are processed by bindings on the
device.
Device Configuration Map#
The FGDeviceConfigurationMap stores the names which a given
device is known by, and additional synthetic names based on USB vendor
and product IDs. Names with a serial number appended are also allowed,
to distinguish between multiple devices of the same type.
The XML syntax for input configuration files is described in the XML input reference.
HID Implementation#
The HID implementation works on all three major platforms, and in fact on any platform supported by the HID API library. The USB HID ‘report descriptor’ is read and parsed directly from the hardware, and used to build the list of events the hardware can generate.
FGHIDDevice is the subclass modelling a HID device, and
FGHIDEventInput is the subsystem which initialises HID-API,
enumerates all the devices, and adds those which have a configuration
defined.
Note that HID-API does not support hot-plugging (yet, see libusb/hidapi), so connecting a device while FlightGear is running, will not make it usable unless the input subsystem is restarted.
Output Data#
Some HID devices support output reports, which can be used to drive LEDs, seven-segment displays or mechanical indicators. There are two different supported approaches: generating specific output events, or creating the USB output report data programmatically. The latter is more flexible, but considerably more complex to implement.
Note that using output data, it is possible to support force feedback devices, but this is not currently implemented. FlightGear itself currently does not model control surface loading in a way that could drive such outputs.