A new patch series proposes a
runtime standby ABI for Linux that mirrors the behavior of Microsoft Windows’ “Modern Standby,” allowing userspace to trigger firmware notifications that make a system
look asleep (display off, status LEDs, etc. while the kernel and selected services remain active. The work — authored by Antheas Kapenekakis and circulated on the kernel mailing lists as an RFC — moves several ACPI _DSM notifications out of the suspend sequence, implements a transition function for those states, and exposes a controlled userspace interface at /sys/power/standby so userland can request the “screen-off → sleep → DRIPS” choreography without fully suspending the kernel. This proposal aims specifically at improving runtime behavior on modern handhelds and laptops where fast resume, background connectivity, and controlled hardware appearance are important.
Background
Modern devices increasingly rely on runtime low‑power models that keep DRAM and some subsystems powered so the system can remain connected and resume quickly. Microsoft’s Modern Standby (S0 low‑power idle) is the most visible example: it defines multiple presentation states (Active, Screen Off, Sleep, DRIPS/Deepest Runtime Idle Platform State, etc. and a choreography that lets the OS and firmware coordinate transitions while preserving a quick resume and background connectivity. That model trades deeper power savings for connectivity and instant‑on responsiveness — a trade most smartphone users accept and that many handheld gaming devices need to strike carefully. Linux historically implements suspend semantics differently: s2idle (suspend-to-idle) reaches DRIPS-like power floors, but the kernel’s suspend and runtime states and the firmware notifications that modify device presentation were primarily invoked as part of the suspend/resume path. The Kapenekakis series reorganizes that behavior so those firmware notifications can be invoked while the kernel is fully active, and then exposes that transition path to userspace. The intent is to let userland orchestrate presentation changes (for example, turn off the display, pulse LED indicators, or adjust USB hub power) without forcing a full kernel suspend.
What the runtime standby ABI proposes
The core technical change
- Move existing ACPI _DSM firmware notifications (notably the ones historically used to change “appearance” during suspend) out of the suspend sequence and into a reusable transition function invoked while the kernel is active.
- Add explicit support for additional _DSM calls, including the Turn Display On call (added by Windows 22H2), to enable fast wake‑up sequences that keep the device logically in a low‑power presentation state while accelerating user‑initiated resume.
- Expose a controlled userspace interface at /sys/power/standby so userspace daemons and desktop environments can request presentation state transitions (Screen Off, Sleep Entry/Exit, Turn On Display, etc. without requiring the kernel to fully suspend.
These are implemented primarily in the ACPI s2idle codepath and in kernel power management plumbing, plus accompanying documentation and a small platform quirk table for hardware that needs timing adjustments. The RFC contains a documentation patch, kernel code changes, and platform driver/quirk updates.
What userland will see
- A sysfs attribute and a documented ABI: userland tools (power managers, desktop environments, and gaming runtime services) can call /sys/power/standby to instruct the kernel to perform the user-visible transition without blocking kernel activity.
- The ability to implement a “display off but still connected” mode: audio playback, downloads, and other background tasks can continue while the screen is off and the device appears to the user as if it were sleeping.
- Faster perceived wake-ups: with Turn Display On support and presentation-aware transitions, the kernel and firmware can optimize to show a rapid resume path while still enabling background activity and maintaining low power use.
Phoronix summarized the motivation as a more comprehensive successor to earlier Collabora work that exposed a /sys/power/lps0_screen_off interface; Kapenekakis’ series generalizes and formalizes those ideas into a broader runtime standby ABI.
Why this matters: practical drivers for the proposal
For handhelds and gaming devices
A large chunk of the patch series’ motivation comes from the handheld gaming ecosystem (OneXPlayer, ASUS ROG Ally, MSI handhelds) where vendors and users need:
- predictable bag safety and lower standby thermal footprint,
- background downloads and music while the screen is off,
- instant resume for controller-first UX,
- and coordinated firmware presentation changes (LEDs, controller hub power) that match user expectations.
Multiple platform-specific bugs (for example, controllers not functioning because a hub didn’t enter D3 at the expected time) are cited as already fixed or mitigated by the new transition model. The patch notes explicitly mention a fix for a ROG Ally controller issue triggered by timing expectations during the suspend choreography.
For desktop and laptop users
Beyond handhelds, laptops that aim to emulate Modern Standby behavior (fast wake, background activity, low battery drain when well‑implemented) will benefit from a unified, documented ABI that userland can use consistently across vendors. This helps distributions and OEMs provide a uniform UX for screen-off connectivity and controlled presentation changes without relying on bespoke vendor utilities.
Strengths and potential benefits
- Better UX parity with Modern Standby: Linux gains an official, kernel-level mechanism for the “screen off but alive” experience that users expect from modern mobile devices. This reduces the need for vendor-specific hacks and userland-only workarounds.
- Explicit, documented ABI: shipping a documented sysfs interface means distributions and desktop environments can integrate predictable behavior rather than probing device quirks silently.
- Fixes real-world device bugs: the patch series already identifies and resolves timing and quirk issues (e.g., controller hub D3 timing), delivering practical fixes for devices shipping in volume.
- Granular presentation control: allowing userspace to select presentation states (Display Off, Sleep Entry, Sleep Exit, Turn On Display) opens new energy-saving modes for background tasks like downloads, media playback, and telemetry while maintaining expected visual cues for users.
Risks, compatibility concerns, and open questions
No kernel change of this scope is risk‑free. Key areas that need careful attention:
- Firmware and driver compatibility: the success of a runtime standby ABI depends on firmware (ACPI/_DSM support) and drivers honoring the new notification timing. Some vendors will require firmware updates or driver adjustments. The RFC already includes a quirk table for hardware needing timing tweaks, but broad device diversity means regressions are possible.
- Reboot persistence of presentation state: the LKML discussion notes that some _DSM effects persist across reboots (a device rebooting from Sleep could boot into Sleep presentation), which is undesirable. A reliable path to clear presentation state on reboot must be finalized; the current series flags this as an area needing further work. This is an example of a behavior that is documented in the RFC and must be handled before broad deployment.
- DPMS and graphics stack interactions: gamescope, KDE, and other compositors may not trigger DPMS (display power management) early enough, leading to frozen screens during transitions. The RFC asks whether the kernel should fire DPMS prior to forcing Sleep for backward compatibility; adding such hooks could be invasive and is unresolved. Graphics drivers/gpus will need careful coordination.
- Security and attack surface: any mechanism that keeps networking active while the display is off increases the importance of network security during these states (for example, attack vectors when the device is unattended). Modern Standby on Windows raised similar concerns, and Linux distributions will need to make policy choices about background connectivity during runtime standby.
- User expectations vs. reality: Without clear UX cues and predictable defaults, users could misunderstand whether a device is fully asleep (zero draw) or in a runtime standby state (some background activity). Good defaults and clear UI are essential, as are tools for users to diagnose wake sources (analogous to Windows’ powercfg /sleepstudy).
How the implementation fits into existing kernel power models
s2idle and DRIPS
The series maps presentation states onto an explicit state machine: Active ↔ Screen Off ↔ Sleep ↔ DRIPS ↔ Hibernate, with transitions exposed and controlled from userspace via the new ABI. The kernel’s s2idle path is the implementation for runtime idle and corresponds to DRIPS. The transition function centralizes callback invocation and makes the firmware notification sequence available without invoking the suspend/resume code path. This reorganizing is a core technical change; it keeps the kernel active while changing firmware presentation.
Where callbacks live
The RFC introduces static callbacks and a transition function in the ACPI s2idle code. It also touches kernel power mainline files to add the sysfs entry and document the new Standby/Presentation states in the admin guide. The series spans documentation, s2idle driver changes, power subsystem hooks, and a small number of platform driver adjustments (e.g., removing older suspend quirks for specific ASUS models).
Verification and independent cross-checks
The main claims in the proposal are verifiable against multiple independent sources:
- The Phoronix write‑up reports the RFC and summarizes the /sys/power/standby interface and the motivation tied to handheld gaming support. It notes the author (Antheas Kapenekakis) and characterizes the work as more comprehensive than prior Collabora patches.
- LWN’s coverage digs into the series content, reproducing the state diagram and noting the movement of _DSM calls out of the suspend sequence, the addition of Turn Display On support, the sysfs attribute, and the practical effects on devices like the ROG Ally controller. LWN’s article also reproduces parts of the LKML commit list and patch description, giving a technical cross‑check for the RFC’s specifics.
- The platform‑driver lists and LKML archives (mirror/readable pages) show the actual RFC threads and patch titles, confirming the files changed and the scope of the changes in drivers/acpi and kernel/power. These mailing‑list mirrors show the series’ file list and insertions/deletions as noted in the RFC.
Taken together, these confirm the technical claims about which _DSM functions were moved, the creation of the transition function, the /sys/power/standby interface, and the short list of platform fixes included in the RFC. Where the public documentation is thin (for example, the internal rationale of certain timing choices or vendor firmware behavior), the RFC explicitly flags those as areas requiring further harmonization; those items should be treated as
operationally described but not fully engineering‑verified until vendor cooperation and broader testing are complete.
What to watch next: testing, adoption timelines, and distro impact
- Kernel review and merge: The RFC nature of the series means it’s intended for comment and revision. Expect follow‑ups, quirk additions, and possible API refinements. Whether it lands in mainline kernel trees will depend on maintainer feedback and whether merging causes regressions across varied hardware.
- Vendor firmware updates: Some vendors will need BIOS/UEFI updates to correctly implement _DSM semantics and to avoid reboot persistence problems; test coverage from OEMs will be crucial.
- Userspace integrations: Desktop environments (KDE, GNOME), Wayland compositors, and power managers will want to add fallback logic and adapt DPMS/DPMS timing to cooperate with the new ABI. Gamescope and compositor maintainers will need to test DPMS firing timing.
- Distribution policies: Distros will need to decide whether runtime standby is enabled by default, and how to present it (e.g., a “screen off but downloads continue” option). Clear defaults and diagnostic tooling will help avoid user confusion.
Recommendations for implementers and power users
- For kernel developers and vendor engineers:
- Run the RFC on representative hardware and log all _DSM call outcomes and reboot states.
- Add explicit transitions to active during reboot paths to eliminate undesirable persistence of presentation effects.
- Work with graphics driver maintainers to ensure DPMS is fired at the right time or that the kernel provides safe hooks for drivers to block transitions if an active CRTC exists.
- For distribution and desktop integrators:
- Expose a conservative policy by default (e.g., require an opt-in or enable only on validated hardware).
- Provide user-facing diagnostics similar to Windows’ SleepStudy, and implement clear UI wording distinguishing “sleep” from “screen off with background activity.”
- For end users and handheld owners:
- Treat early releases as experimental until vendor stacks are tested; back up critical data before trying new power modes.
- Prefer hibernate for long-term storage (bags, flights) if you need absolute power‑off guarantees; runtime standby is about UX and convenience, not zero power.
Final analysis: a pragmatic, iterative step toward Modern Standby parity
The runtime standby ABI RFC is a thoughtful and pragmatic attempt to give Linux a first‑class implementation of the
presentation aspects of Modern Standby without wholesale rearchitecting of the kernel’s suspend machinery. By moving firmware notifications into a transition function and exposing them via a documented sysfs ABI, the patch series provides a stable contract for userspace and paves the way for handheld and laptop vendors to implement consistent, UX-oriented low‑power behaviors.
Strengths of this approach include a clear ABI, targeted fixes for real-world device issues, and a route for userland to orchestrate presentation state transitions. The most immediate risks are hardware/firmware variance, DPMS/graphics stack interactions, reboot‑persistency issues, and the need to ensure that power‑sensitive users are not led to assume zero power drain when the device merely looks asleep.
This is engineering that touches firmware, kernel power code, graphics stacks, and userland — a cross‑stack problem that cannot be fully solved in the kernel alone. The RFC’s explicit documentation, quirk handling, and the fact that it surfaced from developers well‑known in the handheld space are positive signals. However, broad adoption will require vendor cooperation, careful testing, and sensible distribution defaults so the runtime standby ABI becomes a reliable feature rather than a source of surprising behavior.
The proposal is an important step toward parity with Modern Standby and, if merged and iterated responsibly, could materially improve the Linux experience on handhelds and modern laptops. Readers and implementers should follow the RFC thread, test on noncritical hardware, and watch for successor patches addressing the reboot persistence and DPMS questions, which are the two practical blockers to wide, safe deployment.
The kernel mailing‑list RFC and the accompanying documentation patch are public; reviewers and distribution maintainers should prioritize coordinated testing with OEM partners before enabling runtime standby by default in shipping images. The code path, interface, and immediate use cases are clearly articulated in the RFC and covered independently by Phoronix and LWN, but device diversity means real‑world verification remains the essential next step.
Source: Phoronix
New Runtime Standby ABI Proposed For Linux Akin To Microsoft Windows' "Modern Standby" - Phoronix