Vinnerliste

Nei, du må nok lage driveren. Ikke helt umulig, men litt risikabelt å fikle med siden det er udokumentert blind fikling inn i det aller helligste der minst en av funksjonene etter all sannsynlighet starter selvdestruksjonsekvensen. seriøst. Nyttige verktøy: Intels ASL+ kompilator. iasl. Inkludert i Debian-pakken acpica-tools https://github.com/mkottman/acpi_call. Pakket som acpi-call-dkms i Debian Eksempel på hvordan dekompilere DSDT for å se på hva som er tilgjengelig og kalle funksjoner der. Utøves med stor forsiktighet - firmware i en laptop gjør veldig mye rart og er vanligvis skrevet av idioter på crack: apt install acpi-call-dkms modprobe acpi-call cp /sys/firmware/acpi/tables/DSDT /tmp/ iasl -d /tmp/DSDT less /tmp/DSDT.dsl Her ser jeg f.eks denn blokken, som jeg er så heldig å allerede vite har noe med batteri/lading å gjøre Scope (\_SB.PCI0.LPC.EC.HKEY) { Method (PSSG, 1, NotSerialized) { Return (\PSIF (0x00, 0x00)) } Method (PSSS, 1, NotSerialized) { Return (\PSIF (0x01, Arg0)) } Method (PSBS, 1, NotSerialized) { Return (\PSIF (0x02, Arg0)) } Method (BICG, 1, NotSerialized) { Return (\PSIF (0x03, Arg0)) } Method (BICS, 1, NotSerialized) { Return (\PSIF (0x04, Arg0)) } Method (BCTG, 1, NotSerialized) { Return (\PSIF (0x05, Arg0)) } Method (BCCS, 1, NotSerialized) { Return (\PSIF (0x06, Arg0)) } Method (BCSG, 1, NotSerialized) { Return (\PSIF (0x07, Arg0)) } Method (BCSS, 1, NotSerialized) { Return (\PSIF (0x08, Arg0)) } Method (BDSG, 1, NotSerialized) { Return (\PSIF (0x09, Arg0)) } Method (BDSS, 1, NotSerialized) { Return (\PSIF (0x0A, Arg0)) } } Funksjonsnavnene er kryptiske, men det er et visst mønster. Slutter på G => get , Slutter på S => set. Interessant nok ser vi at alle samme kaller den samme funksjonen \PSIF med en id og et argument. Hvis vi av nysgjerrighet kikker litt lenger ned så ser vi hva den er Method (PSIF, 2, NotSerialized) { Return (SMI (0x14, 0x05, Arg0, Arg1, 0x00)) } SMI = System Management Interface. Så der har du magien. Men vi kan prøve et par av get-kallene ihvertfall. Må gjette argumentet, men her jeg så heldig at jeg vet at det er batteri 1 eller 2. Og jeg har bare 1. Så dermed (med echo "" for lesbarheten bare) root@miraculix:/home/bjorn# echo '\_SB.PCI0.LPC.EC.HKEY.BCTG 1' >/proc/acpi/call; cat /proc/acpi/call; echo "" 0x350 root@miraculix:/home/bjorn# echo '\_SB.PCI0.LPC.EC.HKEY.BCSG 1' >/proc/acpi/call; cat /proc/acpi/call; echo "" 0x35a Og så er jeg også så heldig at jeg vet at det bare er den laveste byten jeg er interessert i der, så dermed er svarene 0x50 og 0x5a. Eller 80 og 90 som var det jeg hadde som start og end threshold i prosent. Og jeg kan endre f.eks. stop til 85% med (ettersom alle disse fuksjonene bare tar ett argument så forsvinner magisk nok batterinummeret her): root@miraculix:/home/bjorn# echo '\_SB.PCI0.LPC.EC.HKEY.BCSS 0x55' >/proc/acpi/call; cat /proc/acpi/call; echo "" 0x0 Endringen kan jeg se igjen i driverens grensesnitt: root@miraculix:/home/bjorn# grep . /sys/class/power_supply/BAT0/charge_control_* /sys/class/power_supply/BAT0/charge_control_end_threshold:85 /sys/class/power_supply/BAT0/charge_control_start_threshold:80 Vel, der har du mer enn nok info til å skrive en ACPI-driver for Linux. Og vi har kanskje sporet av nok for i dag. Men håper det er underholdning i det minste

Vet ikke hvordan på en HP, men den riktige måten er å lage en driver som snakker med ECen i laptopen og forteller den hva grensene skal være. Typisk har ECen ACPI og/eller WMI funksjoner for den slags. I Linux er det standardiserte og dokumenterte grensesnittet et par sysfs attributter. Dokumentasjon her: https://www.kernel.org/doc/html/latest/admin-guide/abi-testing.html#abi-sys-class-power-supply-supply-name-charge-control-end-threshold Dersom du har en driver som støtter dette så finner du dem under batteri-objektet i sysfs. Helt sikkert også i diverse GUI-verktøy på toppen, men det er jo mer krøkkete å forholde seg til. På min Stinkpad så har jeg: root@miraculix:/home/bjorn# ls -l /sys/class/power_supply/BAT0/charge_control_* -rw-r--r-- 1 root root 4096 Feb 10 18:14 /sys/class/power_supply/BAT0/charge_control_end_threshold -rw-r--r-- 1 root root 4096 Feb 10 18:14 /sys/class/power_supply/BAT0/charge_control_start_threshold root@miraculix:/home/bjorn# grep . /sys/class/power_supply/BAT0/charge_control_* /sys/class/power_supply/BAT0/charge_control_end_threshold:90 /sys/class/power_supply/BAT0/charge_control_start_threshold:80 Så dermed lader ECen batteriet til 90% og stopper der. Så kjører den maskinen på AC inntil batteriet har droppet til 80% før den begynner å lade igjen. Kan jo ta en del tid når den ikke bruker batteriet. Dette er grenser jeg har valgt og bare lagt inn i de filene der (vha sysfsutils, men det kunne jo like gjerne vært et par echo kommandoer i et boot script). Navnene på driverne som har implementert slikt forteller det meste om hvilke merker du kan forvente at det virker. Dessverre ikke HP ser det ut til: bjorn@miraculix:/usr/local/src/git/linux$ git grep -l charge_control_end_threshold drivers/ drivers/platform/x86/asus-wmi.c drivers/platform/x86/dell/dell-laptop.c drivers/platform/x86/fujitsu-laptop.c drivers/platform/x86/huawei-wmi.c drivers/platform/x86/lg-laptop.c drivers/platform/x86/msi-ec.c drivers/platform/x86/system76_acpi.c drivers/platform/x86/thinkpad_acpi.c drivers/platform/x86/toshiba_acpi.c Noe å tenke på neste gang du handler laptop... Evt er det jo sikkert mulig å implementere på HP også hvis man har tid og ork. Regner med at de har funksjonaliteten i WIndows, så det er jo "bare" å finne ut hva de magiske ACPI eller WMI besvergelsene er