Windows laptops running on ARM processors have gained real traction in recent years. Their mix of efficiency and performance appeals to buyers tired of traditional x86 designs. Yet Linux users often hit roadblocks. Many features stay locked behind vendor-specific interfaces that the open-source kernel simply ignores on non-x86 hardware. A fresh set of patches aims to change that picture.
Developer Armin Wolf submitted a three-patch series on July 17, 2026. The changes target the ACPI Windows Management Instrumentation driver, long restricted to x86 and x86_64 systems. Once merged, the driver core could run on any architecture that supports ACPI. That includes modern ARM64 platforms. The work builds on observations first made by the aarch64-laptops project around 2019.
Some Windows-on-ARM notebooks expose WMI-ACPI mapping devices with the identifier PNP0C14. These devices operate exactly as they do on x86 hardware. They surface hotkeys, sensors, and other vendor controls through WMI. The Linux kernel’s WMI driver core previously blocked their use on ARM because of an explicit architecture check. Wolf’s first patch removes that restriction outright.
“The aarch64-laptops project found out that some Windows-on-Arm notebooks contain WMI-ACPI mapping devices (PNP0C14) that work exactly like on x86,” Wolf wrote in the patch cover letter. “Those devices however are currently not supported by the WMI driver core due to only supporting x86.”
The second patch updates the acpi-video driver. It now takes advantage of the broadened architecture support. The third enables the generic WMI BMOF driver on aarch64. All three patches were tested on an ACPI-based aarch64 virtual machine. They worked without issue. Phoronix first reported the series and quoted Wolf’s explanation in full.
This effort addresses a gap that has persisted for years. Older patches existed on the aarch64-laptops mailing list. They never reached the mainline kernel. Wolf’s submission looks cleaner and more complete. It also aligns with a wider shift toward pure ACPI firmware on future ARM laptops. Qualcomm’s Snapdragon platforms, for instance, are expected to drop Device Tree reliance in Windows-on-ARM designs.
ACPI on arm64 follows a hardware-reduced model spelled out in version 5.1 and later of the specification. The Linux kernel enforces this mode strictly. It ignores 32-bit address fields and certain legacy tables. Only 64-bit entries in the Fixed ACPI Description Table matter. Firmware provides tables through UEFI. Required tables include the Root System Description Pointer, Extended System Description Table, Fixed ACPI Description Table, Differentiated System Description Table, Multiple APIC Description Table, and Generic Timer Description Table.
Drivers on these systems rely on the _DSD method rather than _DSM for device properties. The kernel’s unified property API helps avoid code divergence between Device Tree and ACPI paths. Power management uses standard _PSx and _PRx methods for regulators and clocks. The kernel sets ACPI_OS_NAME to “Linux” by default. All of this creates a solid but limited foundation. Adding WMI support fills a practical hole for real hardware.
The kernel documentation explains how the ACPI WMI interface works in detail. Microsoft defined this proprietary extension to embed WMI objects inside ACPI firmware. Each device carries a unique identifier. A _WDG buffer holds static 20-byte blocks. Each block contains a 16-byte GUID, a two-byte method or notification identifier, an instance count, and a one-byte flag. Flags indicate whether an object represents a method, an event, or expensive data.
Queries go through WQxx methods where the last two characters match the notification ID. Execution uses WMxx. Events can be enabled or disabled with WExx. The kernel’s WMI driver core converts binary buffers into appropriate ACPI data types. Strings arrive as a 16-bit little-endian length followed by UTF-16LE characters and a null terminator. Integers use little-endian format. The conversion logic ensures compatibility with how Windows itself consumes the same data.
The official kernel documentation on the ACPI WMI interface spells out these rules clearly. It notes that buffers must be 8-byte aligned on output. No nested packages are allowed inside ACPI methods. These constraints keep the interface predictable across architectures.
Wolf’s patches do not invent new functionality. They simply let existing code run where it was previously barred. On x86 laptops, WMI has long delivered features such as brightness control, function keys, and thermal sensors. ARM64 equivalents could now gain the same treatment. Laptop makers who ship Windows machines with ACPI-only firmware stand to benefit most.
Support remains unconfirmed for mainline inclusion. Reviewers on the linux-acpi mailing list will examine the series. Past attempts stalled on concerns about code cleanliness or incomplete testing. This version includes explicit VM validation. That may help its case. Even if accepted, real hardware testing will matter. Virtual machines simulate the PNP0C14 devices but cannot replicate every OEM quirk.
A related discussion from weeks earlier proposed a Device Tree-ACPI hybrid mode for Qualcomm Snapdragon laptops. That proposal highlighted the industry’s move toward ACPI-only designs for future Windows devices. ReasonCore covered Wolf’s patches in detail one day after the Phoronix report and echoed the same patch breakdown and testing notes.
Kernel maintainers have expanded arm64 ACPI capabilities steadily. Early support focused on servers. Client devices lagged because most shipped with Device Tree firmware. The rise of Windows-on-ARM changed the equation. Microsoft standardized on ACPI for its ARM platforms. Linux now catches up in stages.
Armin Wolf has contributed other ACPI and WMI fixes before. His name appears on several upstream commits that refined event handling and buffer parsing. This series feels like a logical extension of that work. It removes an arbitrary limitation rather than adding complex new code.
Success here would improve Linux compatibility on devices like the Lenovo ThinkPad X13s and other Windows ARM laptops that surface WMI interfaces. Users could expect better hotkey response, backlight control, and perhaps battery telemetry without custom out-of-tree drivers. The change is modest on paper. Its effect on user experience could prove substantial.
Of course, not every ARM64 laptop uses ACPI. Many embedded boards and development kits still rely exclusively on Device Tree. The patches do not disturb those setups. The WMI driver simply becomes available where ACPI is already enabled. Configuration options remain unchanged. Distributors can still select the driver per platform needs.
So the patches represent quiet but meaningful progress. They erase an old x86 assumption buried in the driver. They let the kernel treat ARM64 systems with equal respect when WMI data appears. And they do so without rewriting large sections of code. That restraint may improve chances of quick acceptance.
Watch the linux-acpi list for feedback. If no major objections surface, the changes could land in a near-term kernel release. Hardware vendors and distribution maintainers will take notice. For Linux on ARM laptops, every enabled interface counts.
WebProNews is an iEntry Publication