.. SPDX-FileCopyrightText: 2026 James Turner .. SPDX-License-Identifier: GPL-2.0-or-later Input Subsystem =============== Abstract classes ---------------- The base input classes are :cpp:class:`FGEventInput` (a :term:`subsystem`), which creates and owns a number of devices (subclasses of :cpp:class:`FGInputDevice`). Using some I/O source, an implementation generates *events*, which are processed by bindings on the device. Device Configuration Map ------------------------ The :cpp:class:`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 :doc:`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. :cpp:class:`FGHIDDevice` is the subclass modelling a HID device, and :cpp:class:`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 https://github.com/libusb/hidapi/tree/connection-callback), 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. .. toctree:: :maxdepth: 2 :caption: Classes classes/FGInputDevice classes/FGInputEvent classes/FGDeviceConfigurationMap