Yeah. ACPI's AML bytecode is sort of a mixed blessing. It allows for reverse engineering and end user analasys/fixing of bugs like this.

It's also just a terrible disaster of a programming environment, with a very large (terrifyingly so, given the limited capability) interpreter that needs to live at the highest privilege level of the kernel.

And it's generally used like a hatchet by system integrators for tricks like this, with pretty much exactly the code quality you'd expect. Almost always the path to writing a Linux driver for some oddball laptop subsystem starts with "throw away the ACPI stuff".

▲

somat 6 days ago | parent | next [-]

As far as I know there are three ACPI AML stacks, the reference intel one, linux uses this, miscrosoft has one, and those crazy hackers over at the openbsd project decided to make their own.

▲

ajross 6 days ago | parent | next [-]

I think that's right. Though my understanding is that the Windows code is derived from the original Intel one too and has evolved in tandem with the Intel-maintained driver. And... yeah, acpica (drivers/acpica/acpica) is just huge; I checked again and it's at 2.5MB of source code. All for a DSDT table parser and a virtual machine with about the capability of a 6502.

▲

bityard 6 days ago | parent | prev [-]

and off by one errors

	▲	butlike 5 days ago \| parent [-]
		and off by one errors

▲

rangestransform 5 days ago | parent | prev [-]

This is why I prefer having my software vendor write native code to interface with the machine instead of stupid bodges like acpi

Windows laptops are dead on arrival for me, all windows laptops are physical shovelware

	▲	ajross 5 days ago \| parent [-]
		But again, AML disassembly may show that it was bad code, but it's at-least-mostly-working code, and provided in a form that can be disassembled and inspected. Lots and lots of robust Linux drivers have been written based on analysis of garbage ACPI integration. Mixed blessing, but still more blessing than curse.