I took a closer look at the power button issue and found the problem. I followed the instructions at https://wiki.archlinux.org/title/DSDT to validate the fix:
[ 0.003658] ACPI: DSDT ACPI table found in initrd [kernel/firmware/acpi/dsdt.aml][0x820f]
[ 0.003800] ACPI: Table Upgrade: override [DSDT-ALASKA- A M I ]
[ 0.003801] ACPI: DSDT 0x000000006E268000 Physical table override, new table: 0x0000000078ACE000
[ 0.003803] ACPI: DSDT 0x0000000078ACE000 00820F (v02 ALASKA A M I 0107200A INTL 20250404)
[ 0.003864] ACPI: Reserving DSDT table memory at [mem 0x78ace000-0x78ad620e]
sudo dmesg | grep ACPI | grep button
[ 0.340918] ACPI: button: Power Button [PWRB]
The problem is in the section @AndrewC pointed out above:
`
Scope (SB)
{
Name (CMBS, 0×01)
Device (PWRB)
{
Name (HID, EisaId (“PNP0C0C”) /* Power Button Device */) // HID: Hardware ID
Name (DDN, “Power button”) // DDN: DOS Device Name
Method (STA, 0, NotSerialized) // STA: Status
{
Name (PSTA, Zero)
M460 (“PLA-ASL-\_SB.PWRB.STA = 0xB\n”, Zero, Zero, Zero, Zero, Zero, Zero)
If ((CMBS == Zero))
{
PSTA = 0×0B
}
Return (PSTA) /* \_SB_.PWRB._STA.PSTA */
}
}
`
Reading that code, CMBS is always 1, meaning that PSTA always returns zero (sorry, I don’t know why the formatting is messed up).
Applying the attached patch makes the button appear to the OS:
It is not clear to me what the meaning of CMBS is here and if the correct value for PSTA should be 0x0B or 0x0F but the method has to return one or the other and not Zero, that’s for sure.
Here is the meaning of those return values of PSTA:
0x0B (binary 1011):
* Bit 0: Present
* Bit 1: Enabled
* Bit 2: Not shown in UI
* Bit 3: Functioning properly
0x0F (binary 1111):
* Bit 0: Present
* Bit 1: Enabled
* Bit 2: Shown in UI
* Bit 3: Functioning properly
@Beelink CS-Bettie could you please forward this information to the R&D Team so that they can fix the DSDT?
