Re: Powerdevil not recognizing that my laptop is plugged in!
He contacted his laptop vendor and asked for a BIOS update. They sent him an ISO from which he was able burn in a BIOS update (burned new, updated code into the BIOS firmware). That new firmware enabled a boot which recognized his AC power adaptor. CAUTION! This is an error prone procedure which, if done incorrectly, could brick your laptop. Consult the vendor about sending in your laptop to have the BIOS firmware updated.
The problem, it appears, stems from Windows poor compiler, and the OEM's willingness to allow a sloppy compiler pass too many errors, allowing Windows to see the AC power adapter, but not an OS that plays closer to the standards:
Originally posted by Nos4ah2
The problem, it appears, stems from Windows poor compiler, and the OEM's willingness to allow a sloppy compiler pass too many errors, allowing Windows to see the AC power adapter, but not an OS that plays closer to the standards:
The ACPI Specification defines the requirements for the DSDT (and everything else, for that matter) pretty explicitly. Intel's ASL compiler, iasl, used to compile the DSDT to AML from ASL, will throw errors and warnings if the underlying ASL is buggy. Unfortunately, Microsoft's ASL compiler allows many of these errors and warnings to sneak by. As a result, many OEMs write buggy DSDTs, and it turns out that Windows is very forgiving of bugs in the DSDT that get by Microsoft's compiler (not surprisingly).
What this means is that a DSDT that does not conform to the ACPI specification will work under Windows, even though it shouldn't. However, when you try to use it in Linux, where the ACPI developers expect that the DSDT is written to comply with the standard (and the Intel ASL compiler), the buggy sections of the DSDT are unsupported. If you have a buggy DSDT, ACPI may not be aware that certain devices exist. Or, if it is aware, it may not support all of their capabilites. If you have either of these symptoms (missing or incompletely supported functionality in /proc/acpi), then the cause may be a buggy DSDT.
What this means is that a DSDT that does not conform to the ACPI specification will work under Windows, even though it shouldn't. However, when you try to use it in Linux, where the ACPI developers expect that the DSDT is written to comply with the standard (and the Intel ASL compiler), the buggy sections of the DSDT are unsupported. If you have a buggy DSDT, ACPI may not be aware that certain devices exist. Or, if it is aware, it may not support all of their capabilites. If you have either of these symptoms (missing or incompletely supported functionality in /proc/acpi), then the cause may be a buggy DSDT.
Comment