UEFI Simple Pointer Protocol Explained

The Unified Extensible Firmware Interface (UEFI) Simple Pointer protocol provides a standardized interface for interacting with relative pointing devices such as mice, trackballs, and touchpads during the pre-boot phase. This article explores the architecture, core data structures, and operational mechanics of the EFI_SIMPLE_POINTER_PROTOCOL, detailing how firmware and pre-boot applications capture user input before an operating system loads.

Core Function of the Protocol

The primary role of the Simple Pointer protocol is to abstract pointing device hardware into a platform-independent model based on relative motion. Unlike modern operating systems that handle complex multi-touch gestures and high-precision absolute coordinates natively, UEFI environments often require lightweight, low-overhead input handling. The protocol standardizes input events so that pre-boot environments—such as UEFI shell tools, boot managers, and BIOS setup utility screens—can implement a graphical cursor.

Key Components and Architecture

The protocol is defined within the UEFI specification as EFI_SIMPLE_POINTER_PROTOCOL. When a pointer device is initialized by firmware, the corresponding driver installs this protocol on the device handle.

The protocol structure consists of the following primary members:

  • Reset(): A function that resets the pointer hardware to its initial state, clearing any internal buffers and pending movement data.
  • GetState(): A function that retrieves the current state of the pointer device and resets the internal relative counters back to zero.
  • WaitForInput: An event triggered whenever the pointer device has new state data available, allowing applications to block or wait efficiently rather than continuously polling the device.
  • Mode: A pointer to an EFI_SIMPLE_POINTER_MODE structure that contains runtime details about the device, including whether a pointing device is physically present and its movement resolution along the axes.

Data Reporting: The EFI_SIMPLE_POINTER_STATE

When an application calls GetState(), the protocol populates the EFI_SIMPLE_POINTER_STATE structure. This structure tracks relative changes since the last poll:

  • RelativeMovementX: An integer indicating movement along the horizontal axis. Positive values indicate movement to the right; negative values indicate movement to the left.
  • RelativeMovementY: An integer indicating movement along the vertical axis. Positive values typically indicate movement downward; negative values indicate movement upward.
  • RelativeMovementZ: An integer indicating movement along the scroll axis, commonly tied to a mouse scroll wheel.
  • LeftButton: A boolean value that evaluates to TRUE if the primary pointer button is actively pressed.
  • RightButton: A boolean value that evaluates to TRUE if the secondary pointer button is actively pressed.

Because the coordinates are relative rather than absolute, the consumer application is responsible for maintaining the cursor's absolute screen coordinates, applying acceleration curves, and enforcing boundary constraints against the display resolution.

Simple Pointer vs. Absolute Pointer

UEFI provides two distinct pointer protocols:

  • Simple Pointer Protocol: Designed for relative-coordinate devices like mice. Coordinates represent the distance and direction moved since the previous read.
  • Absolute Pointer Protocol: Designed for devices mapped directly to a display surface, such as touchscreens and digitizers. It returns absolute X, Y, and Z positions within a predefined coordinate range.

The UEFI Simple Pointer protocol serves as the foundation for desktop-style navigation in firmware, enabling hardware-agnostic cursor tracking with minimal overhead.