This is actually misinformed, the discussion on the mailing list made it clear: there is NO full ACPI on these Windows ARM devices; they only use ACPI marginally and still require and provide device tree.

Phoronix should have revised that article, it's completely misleading.

One option would be to implement the custom non-standard Qualcomm drivers that technically it needs to implement anyway, but with support for the UEFI/ACPI interface.

On Windows, Qualcomm ships custom drivers that override normal ACPI platform logic in various places, IIRC

Not an easily feasible option notably because the firmware ACPI tables are in part stubs - but work on hybrid ACPI/DT instead is possible.

One of the reasons is that Qualcomm uses supplemental ACPI tables (think device tree overlays) shipped inside of the driver packages. Look at the .bin in plenty of the drivers carefully and you'll see that they're supplemental ACPI tables.

Windows doesn't have such a notion and it's implemented via having an ACPI table loader statically linked in to individual drivers.

_On top_ of that, Qualcomm uses PEP to intercept plenty of ACPI functions and implement them in native code instead.

I was thinking essentially about Linux equivalent of PEP.

Of course my preferred setup would be for systems to actually ship compliant UEFI instead of Qualcomm shitshow

There is also ARM SystemReady which is an existing spec for this mainly intended for servers. But it’s not being followed well.

It’s crazy to need a million device trees on server or laptop class devices.

https://news.ycombinator.com/item?id=45086346