Incompatible ACPI

Posted Aug 26, 2025 16:12 UTC (Tue) by tobhe (subscriber, #157486)
In reply to: Incompatible ACPI by pizza
Parent article: Adding stubble to Ubuntu's generic Arm64 Desktop ISOs

> This "solution" combines the worst parts of all worlds, with none of the benefits.

I too would prefer proper ACPI but I don't think "no benefits" is entirely true. PEPs like device trees do have one advantage:
The logic is much easier to update as part of the kernel.

Neither Microsoft nor Qualcomm can easily push firmware updates on those devices, that would have to go through the OEMs and have to be signed with their keys. Splitting structure and logic does make some sense in that context. The hierarchy is static and ideally doesn't ever need to be updated while the code can be maintained and updated like any other piece of software (vs hard to update firmware).

Incompatible ACPI

Posted Aug 29, 2025 12:16 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> PEPs like device trees do have one advantage: The logic is much easier to update as part of the kernel.

That's the sliver lining of what is otherwise a massive downside: The kernel has to still be specifically aware of the nuances of *that particular system* for it to function properly.

> Neither Microsoft nor Qualcomm can easily push firmware updates on those devices, that would have to go through the OEMs and have to be signed with their keys

How exactly is this any different from how PCs with UEFI have worked for the past decade? (Or over 2 decades if you include pre-UEFI ACPI)

Incompatible ACPI

Posted Aug 29, 2025 20:44 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> How exactly is this any different from how PCs with UEFI have worked for the past decade? (Or over 2 decades if you include pre-UEFI ACPI)

UEFI/ACPI both have been insufficient for anything complicated or custom. So we got drivers based on WMI (Windows Management Instrumentation) for things like backlight control. They are mostly trivial, though. I'm not sure that writing a custom driver is much worse than having to deal with per-device quirks and opaque firmware updates that might not be tested with Linux.