# Palomino - Input Module

©2004,2009 Jim E. Brooks http://www.palomino3d.org

- Index
- Overview
- Device Class
- Actions
- Input Queue
- Joystick

## Overview

[2009/11]

The low-level input module consists of Device classes for keyboard, joystick, and mouse. The purpose is to abstract input devices as a system-neutral event queue. The input module defers final responses to higher-level modules.

### Device Class

A Device class consists of:

- system-specific code to enable and access device
- a device-specific Event struct
- input queue
- broadcasting events to listeners when enqueued

    +------------------------------------------------------------------+
    | base template   -->  sys-neutral     -->  private sys-specific   |
    | template class       singleton/factory    instance               |
    +------------------------------------------------------------------+
    | Device          -->  KeyboardDevice  -->  KeyboardDevice[System] |
    |                      JoystickDevice  -->  JoystickDevice[System] |
    |                      MouseDevice     -->  MouseDevice[System]    |
    +------------------------------------------------------------------+

KeyboardDevice etc are a special kind of Singleton that acts like a Factory by instantiating a system-specific derivative of itself.

### Actions

1. Devices are initially disabled to let program become ready.
2. The singletons KeyboardDevice etc instantiate a system-specific derivative of themselves.
3. A Device object reads input from its device-driver.
4. Creates an system-neutral Event struct.
5. Puts an Event into its queue.
6. Broadcasts to registered listeners that an Event is ready in its queue.
7. Alternatively, the consumers can poll the input queue instead of registering a listener.
8. Input queue might overflow older events (on slow systems).

## Input Queue

[2004/11..2009/11]

A Device class has an input queue. Once enabled, one consumer is needed to drain the input queue. A consumer can be either an "event listener" or a "poller". The problem of chaining listeners/pollers isn't addressed in this design.

Once a Device is enabled, it will actually remain enabled even if Device::Enable(false) is called. The device will be logically disabled by disabling the software input queue, not the hardware device.

By design, the input queue has a tiny capacity: it will overflow after a few events remain enqueued. The reason is to make the program seem more responsive by giving priority to the most recent input events. If the queue was large, the program would keep processing events that were several seconds old and so would respond too slowly.

### System-Specific

Linux joystick driver queues events. Windows joystick driver samples the joystick's current state.

## Joystick

[2008/01..2009/11]

There are two unrelated Joystick classes: input::JoystickDevice and control::Joystick. control::Joystick is the consumer of events enqueued by input::JoystickDevice. control::Joystick has higher-level functionality (such as joystick calibration and controlling the current craft).

Last modified: Sat Nov 7 14:51:52 CST 2009