Ladelimit ist eine Anzeige, Akku-Kachel sagt etwas, Menüleiste bekommt Kürzel

Der Regler war eine Pseudobedienung. Der SMC lehnt Schreibzugriffe auf CHLT
ab — der Helfer hat es mit korrekter Größe versucht und „geschrieben (false),
zurückgelesen 85" gemeldet. Das Sicherheitsnetz hat also die Wahrheit gesagt;
die Oberfläche hat sie nur nicht gezeigt.

Weiter zu raten hieße, im Lade-Subsystem Keys durchzuprobieren, und das ist
die eine Operation in diesem Projekt, die Hardware dauerhaft beschädigen
kann. Also: das Limit wird gelesen und angezeigt, mit einem Weg in die
Systemeinstellungen, wo es tatsächlich geht. Der Schreibpfad ist aus dem
privilegierten Helfer entfernt — ein Root-Dienst trägt nur, was benutzt wird.

Die Akku-Kachel zeigte „40 %" und einen Verlauf über die letzten Sekunden.
Der Ladestand ändert sich in Minuten, nicht in Sekunden; der Graph war eine
waagerechte Linie. Jetzt: verbleibende Zeit bzw. Zeit bis voll, Leistung in
Watt mit Richtung, Ladelimit, Zustand, Zyklen — und der Energiesparmodus.
Der erklärt, warum die Maschine langsamer wirkt, und ohne diesen Hinweis
sucht man den Grund woanders.

In der Menüleiste standen fünf nackte Prozentzahlen nebeneinander. Man sah
Zahlen und wusste nicht, welche wozu gehört. Zwei neue Darstellungen: Kürzel
und Wert („CPU 34 %") sowie Symbol und Wert. Beim Akku stehen sie zuoberst in
der Auswahl.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Scarriffle
2026-08-11 12:37:04 +02:00
parent 5ba9e551a4
commit 386eb6ae70
19 changed files with 1763 additions and 1329 deletions

View File

@@ -72,7 +72,39 @@ Vorhanden ist stattdessen ein umfangreicher `CH*`-Satz. Plausible Kandidaten:
**Das bleibt Vermutung, und Vermutungen werden hier nicht geschrieben.** Ein falscher Wert im
Lade-Subsystem ist die eine Operation in diesem Projekt, die Hardware dauerhaft beschädigen kann.
### Nächster Schritt: Differenzmessung statt Raten
### Nachtrag 11.08.2026: Key gefunden, aber nicht beschreibbar
Die Differenzmessung hat ihn geliefert. Der Key heißt **`CHLT`**, Typ `hex_`, drei Bytes:
| macOS-Einstellung | `CHLT` |
|---|---|
| 80 % | `50 01 00` |
| 85 % | `55 01 00` |
| 95 % | `5F 01 00` |
Erstes Byte ist die Prozentzahl, zweites offenbar „Limit aktiv", drittes unbenutzt.
Drei Messpunkte, weil einer Zufall sein kann: `BACC` passte beim ersten Vergleich ebenfalls —
ein Zähler, in dem gerade `50` stand. `ChargerConfiguration` aus `ioreg` sah mit niedrigem
Byte `0x50` ebenfalls wie eine Quelle aus, blieb aber unverändert, als `CHLT` längst auf 95
stand.
**Schreiben scheitert.** Der Helfer hat es mit korrekter Größe (3 Byte) versucht; der
SMC-Userclient gibt einen Fehler zurück, der Wert bleibt stehen:
```
Ladelimit: 95 % gewünscht, 95 % geschrieben (false), zurückgelesen 85 %
```
macOS setzt das Limit also auf einem anderen Weg. Welchem, ist offen — und weiter zu raten
hieße, im Lade-Subsystem Keys durchzuprobieren. Das ist die eine Operation in diesem Projekt,
die Hardware dauerhaft beschädigen kann, also unterbleibt es.
**Folge für Onyx:** das Ladelimit ist eine **Anzeige**. Der Wert wird gelesen und im
Akku-Widget sowie im Akku-Popover gezeigt, mit einem Weg in die Systemeinstellungen. Der
Schreibpfad ist aus dem privilegierten Helfer wieder entfernt — ein Root-Dienst trägt nur,
was benutzt wird.
### Damals geplanter Schritt: Differenzmessung statt Raten
macOS hat selbst eine Ladebegrenzung (Systemeinstellungen → Batterie → Batteriezustand →
„Optimiertes Laden" bzw. das 80-%-Limit). Wird sie umgeschaltet, muss sich der zuständige