There are still people who hope that WoA (Windows on Arm) devices based on Qualcomm SoCs will get ACPI mode working with Linux.

This would require Qualcomm to write a new firmware for each of their WoA SoC. Then all ODM/OEM to prepare firmware update.

For devices where list of components which "do not work or still have problems" is longer than "works fine".

I like that people from Linaro/Qualcomm work on getting WoA devices running with Linux but that's more for hobby than normal users.

@hrw More for hobby? Really? I don't think you ever really looked at this... I use Lenovo T14s laptop (so Qualcomm ARM64 SoC based) since half a year, and except totally broken hardware charging (independent of Linux), Linux works fine. That's not a hobby.

@hrw ... and by use, I mean daily use, completely replacing my previous machine.

@krzk I saw Linaro Connect 2024 session and it was full of "not yet" entries.

Then I watched 2025 one: https://www.youtube.com/watch?v=2JOsQToPt00 and it feels like there were improvements since 2024 but still Linux on WoA devices is for those who know how to workaround issues (or ignore missing things) rather than for normal users.

You are a developer. You know how to live with missing things.

@hrw No, I use it as an user, not as a developer. I don't tweak it, I don't fix it, I don't develop it.

It is true Linux is missing some things (e.g. camera), but ACPI won't solve it either, because they will be missing on ACPI as well.

Your push towards ACPI won't solve most of the problems Qualcomm platforms have - incomplete upstream support - because you still need to develop drivers, either for ACPI or for DT.

@krzk I do not push for ACPI on devices which do not have it properly done in firmware.

DeviceTree is THE solution for most of Arm hardware.

Sure, it is sad to see when it is the only solution to provide hardware info because firmware is broken (like on WoA devices).

@hrw it's not possible for existing SoCs.

The reason is that you can't do breaks like this after shipping. It'd force a windows reinstall with a new drivers set

@hrw why can't Linux be upgraded to read (and understand) the existing ARM ACPI tables?

@linrunner @hrw QCOM doesn't really implement actual ACPI on those, but something that can be called QCPI.

Quick tldr: ACPI tables in firmware are incomplete, and the drivers ship with an ACPI table parser *inside* and ACPI table overlays as .bin.

Of course that's completely incompatible with anything that isn't the QCOM driver set (and then that's not the only problem)

@never_released so it is just the usual inane hide my IP game. I see.

@linrunner not a deliberate game to hide IP

As far as I remember, it ended up with a fun roadblock because Windows has a 32k max functions cap on the DSDT, and the QCOM dsdt was insane enough to reach that so they did the quickest thing and split it out instead of a rethink

@linrunner with a lot of this being inherited from the windows phone/RT era

@never_released @hrw
And frankly, depending on generation, it ultimately wouldn't be possible for hardware reasons (once you let people punch through abstraction layers, they _will_ use that for mischief).

Plus relying only on current ACPI spec for power management would mean a big hit to battery life compared to what the PEP lets you do.

@never_released @hrw Is the root problem with the ACPI tables and firmware, or that the SOC HW is, as accessible in EL2/EL1 itself, far from BSA standards?

@sdbbp @hrw depends on SoC - for Makena its target market had a significantly more sane firmware setup (automotive) - but Windows (8cx Gen 3) got the Windows thing

@sdbbp @hrw and as accessible from EL2 is what actually matters - if you run UEFI at el1 you've already lost

(And that's something QCOM is/was addicted to)

@hrw @krzk Exactly how many years are going pretend devices with properly done ACPI are going to exist? It kind of works on servers because nobody really cares of power management in there. But even on X86 laptops the experience is mediocre despite the high level of homogenity of underlying HW. My "hand-selected for good Linux compatibility" x86 laptop has a 30% chance of failing to suspend properly...

@hrw @krzk The only non-ACPI supporting laptop is running around the competition in performance and battery life - and nobody is asking the vendor to "do proper ACPI firmware or it will never be supported in Linux"

@hrw

That is pre-supposing that this is not a linux problem to solve

I'm still on the fence about dt vs acpi (former cleaner, latter what we have to live with).. but in the latter case maybe we need to solve the problem on the linux side like we have in the past with x86 devices (and I assume future x86 devices)

@robclark @hrw
This problem isn't solved for x86, microsoft just didn't let those vendors get away with the same level of bamboozling (which also limits their ability to achieve amazing power management).

@suihkulokki @hrw @krzk and if anything x86 laptops are going closer to what we see in arm devices - now with weird camera interfaces, potluck on where the keyboard is connected to etc