Lifetime of a button press

Detailed Description

The lifetime of a button press for peripherals with input.

Introduction

Note

This documentation assumes you have the source code for Kodi and peripheral.joystick open in front of you. The fixed-width font is the class or struct you should reference.

When a controller is plugged in and a button is pressed, it starts a large chain reaction of different systems. The button's journey is destined to reach one or more eventual outcomes:

• An emulator / game add-on
• Kodi's input system
• A configuration utility

Game input

Instead of being forced to use a single controller abstraction, game add-ons can request input in the form of any platform controller known to Kodi. For example, a NES emulator receives input events for a NES controller; if the emulator doesn't care, it receives events for a default 360-style controller.

Kodi's input system

If no game is receiving input in fullscreen mode, the button is translated to the default 360-style controller and Kodi's keymapping system takes over from here

Configuration utilities

A configuration utility needs know the button's driver index in order to map it to a feature on its controller. In addition to raw driver events, it also needs to promiscuously monitor the input translated to its platform controller to highlight features in the GUI as they're pressed.

The final system can handle any number of these input listeners, monitoring input in the form of any number of platform controllers

‍some class names are outdated, sorry

Topics
	1. Scanning for peripherals
	2. Receiving joystick events
	3. Handling events
	4. Handling input for the Game API
	5. Mapping driver elements to the system's controller
	6. Translating Kodi controller to libretro's "RetroPad"
	7. Kodi Input
	8. Button mapping (controller configuration)
	9. Keyboard input