How GIMP Detects USB Drawing Tablets Without Restarting

Modern releases of the GNU Image Manipulation Program (GIMP) can detect hotplugged USB graphics tablets in real time without requiring an application restart. This capability is made possible through a multi-layered, event-driven pipeline that coordinates low-level operating system device managers, the display server's input subsystem, the underlying GIMP Toolkit (GTK) layer, and GIMP's internal input device manager.

Operating System Kernel and Hardware Detection

When a USB graphics tablet is connected, the host operating system's kernel detects the hardware interrupt and enumerates the device via its Human Interface Device (HID) descriptors.

  • Linux: The kernel generates a uevent, which is intercepted by the user-space device manager (udev). The input driver (typically evdev or hid-multitouch) exposes device nodes under /dev/input/.
  • Windows: The kernel notifies the subsystem, broadcasting a WM_DEVICECHANGE message to listening window handles.
  • macOS: The IOKit framework detects the dynamic hardware attachment and notifies registered listeners.

The Input Processing Layer and Display Server

Once the operating system recognizes the tablet, the display server must ingest the device to route its input events to active application windows.

On Linux environments, libinput processes the raw tablet data (including coordinates, pressure levels, and tilt). It forwards this information to the display server:

  • Under Wayland, the compositor handles the dynamic input seat configuration directly.
  • Under X11, modern configurations utilize XInput2 (XI2). Unlike the legacy XInput 1.x standard—which required input devices to be defined in static configuration files prior to starting the X server—XInput2 supports dynamic device hierarchy changes and broadcasts dynamic device events.

GTK and GDK Device Management

GIMP is built on the GTK framework, which delegates low-level platform integration to the GDK (GIMP Drawing Kit) library.

GDK provides an abstraction layer over platform-specific display systems via objects such as GdkDeviceManager and GdkSeat. GDK continuously listens to the windowing system for input hierarchy changes:

  • In X11, GDK listens for XI_HierarchyChanged events.
  • In Wayland, it monitors the wl_seat capabilities and device binding protocols.
  • In Windows and macOS, it hooks into their respective platform event loops.

When the tablet is plugged in, the GDK backend instantiates a new GdkDevice representing the tablet pointer, stylus, or eraser, and emits a device-added signal.

GIMP's Internal Device Architecture

Within GIMP's own codebase, the detection and management of input hardware is handled primarily by GimpDeviceManager and GimpDeviceInfo:

  1. Signal Subscription: At startup, GimpDeviceManager attaches callbacks to GDK's device notification signals, specifically listening for device-added and device-removed.
  2. Device Registration: Upon receiving a device-added signal, GimpDeviceManager allocates a new GimpDeviceInfo object. This object wraps the GdkDevice, querying its hardware capabilities, such as supported axes (X, Y, pressure, tilt, wheel) and keys.
  3. Preset Mapping: GIMP compares the hardware identifiers (Vendor ID and Product ID) against its user configuration files (devicerc). If the tablet was configured in a prior session, GIMP automatically restores the user's axis calibrations, curve profiles, and tool associations without user intervention.
  4. Context Activation: The new device is integrated into GIMP's active context, enabling the user to immediately paint with pressure sensitivity. If the tablet is unplugged, GDK emits device-removed, prompting GIMP to cleanly release the device context while retaining its configuration profile in memory.