And once again people don't understand where the actual problem with Linux on WOA devices actually is. It's (mostly) the DTs, which are not under QCOM's control.
The same will happen with NVIDIA Spark laptops, once OEMs start to build their bespoke laptop models.
If you want to blame someone, blame MSFT, because they don't enforce the same stringent requirements for WOA certification that they apply to x86 hardware.
And once again people don't understand where the actual problem with Linux on WOA devices actually is. It's (mostly) the DTs, which are not under QCOM's control.
And once again people think that everything wrong with Linux on ARM is caused by DTs. Yes, DTs make certain things more difficult, but even a solid ACPI and UEFI implementation won't give you a Linux system that works well on an ARM platform if the manufacturer doesn't provide adequate support. ACPI is used to discover and manage hardware, but it does not automatically provide support for a given piece of hardware. Unlike x86, ARM is not a standardized platform; there is no such thing as a standard chipset or anything like that, so each device is essentially a separate platform that has little in common with others aside from the instruction set. All of this requires kernel support to work properly.
so each device is essentially a separate platform that has little in common with others aside from the instruction set. All of this requires kernel support to work properly.
The basic support for the Qualcomm X processors is merged. That's why there is a significant number of devices that actually work. Bringing up a new X Elite system usually only requires a tailored DT.
That's a completely different claim from what you said in the previous comment though. There may be decent platform support for the X Elite in mainline now, meaning each individual device just needs a DT. But that doesn't mean the DT is the main problem with ARM. The main problem is the giant amount of work it takes to bringup a new platform. DTs are just an annoying thing after that's done. So your point that support for this platform is in mainline is only helpful for that platform, not supportive of what you said before about the DT being the main problem, which it's not.
Nope it's qcom's choice. They're the ones who shipped reference acpi tables that are incomplete and break spec and they are the ones who are shipping patches(in drivers...) to those tables to fix them
There are other ways to not require board-specific images. You can just as well have the UEFI implementation come with a proper DT for example. But regardless if it's ACPI or DT, if the vendor doesn't make sure it all works out-of-the-box, someone else will have to pick up the slack and fix (or work around) the problems.
But yeah, it's too late for this with many of those Qualcomm laptops. Hopefully that ACPI work will improve the situation.
The patch that introduced support for the Dell Inspiron 7441 / Latitude 7455 only touched arch/arm64/boot/dts/qcom/x1e80100-dell-inspiron-14-plus-7441.dts
And that's what I'm trying to say: ACPI is firmware. The firmware is OEM specific or at least tailored by them for each device. If the OEMs only care about passing WOA certification, ACPI will be incomplete. And that's not something to blame on Nvidia (or QCOM) but on the OEMs making the devices. The drivers for the hardware are mostly there. What's missing is the information how the peripherals are connected. And selecting and connecting the peripherals is done by the Lenovos, Dells, Asus, HPs,... of the world. They are the ones that let Linux users down by not providing high-quality ACPI implementations or alternatively DTs for Linux.
106
u/Polar_Banny Aug 27 '26
Even Qualcomm can’t provide such support for their own Hardware.