[abalakh]

Since frame pacing (cb3659dc8, dd7fbe1d3, 287b80b5c), views ask for input with a 1 ms timeout and draw a frame on every pass, so a screen nobody touches is redrawn 60 times a second, or as fast as the device manages. KeyWatcherController also ignores its timeout, so every wait with one spins a core: the screensaver's wait for a press, the Menu combination check.

• KeyWatcherController.get_input() sleeps on a Condition that the reader thread notifies, until a key, a wake or the timeout, and returns as soon as a key comes. clear_input() drains without waiting.
• ControllerInterface.wake() ends a wait from any thread (a notify, or an SDL user event); Controller.request_redraw() uses it, and the volume and hardware-key watchers call it.
• Display compares each frame's draw calls with the previous frame's.
• Controller.get_input() with the default timeout keeps today's rate while the screen changes or was used in the last 1.5 s, then waits up to a second between frames (the clock, the battery icon).
• The standalone in-game listener passes a 0.1 s timeout, and the desktop device's wait:N ticks request a redraw.

Apps that change the screen from another thread can call Controller.request_redraw(). Otherwise the change shows at the next idle frame, within a second.

CPU of the process over 20 s without touching the device, on a Miyoo Mini+ (Spruce 4.5.5 nightly of 2026-10-19), from /proc/<pid>/task/*/stat:

Screen	Before	After
Main menu	37.5% of a core	5.0%
Main menu, screensaver on	98%	1.4%
Cheevos home	68%	6.2% (while a sync ran)
Cheevos, screensaver on	99.5%	1.4%

Also checked on a Mac (DESKTOP) - the launcher's main menu went from 9.0% to 1.5% of a core.