Import-Notizen aus `onexplayer-superxcontrol`

Stand: 2026-05-26 Quelle: https://git.nepharius.at/nepharius/onexplayer-superxcontrol Lokal gespiegelt nach: /home/nepharius/.cache/onexplayer-superxcontrol-old

Kurzfazit

Ja, das alte Repo ist brauchbar. Nicht als fertige Wahrheit, aber als ziemlich gute Spurensammlung.

Am wertvollsten für SuperX-goes-Arch sind daraus gerade vier Blöcke:

alte konservative HID-Paketfamilie für 1a86:1305 Interface 02
klare Trennung zwischen funktionierendem Keyboard-/internem RGB-Pfad und blockiertem Deckel-/Logo-Pfad
Frostbay-Tooling und BLE-/Status-Skripte als Referenzbasis
WMI/CMS/EC-Testwerkzeuge für den Fall, dass wir den proprietären OEM-Pfad weiter einkreisen müssen

Was das alte Repo explizit behauptet

1) RGB-Hauptkandidat

USB VID:PID 1a86:1305
Interface 02
typischer Linux-Pfad: /dev/hidraw2
udev-Regel im alten Repo erlaubt genau diese Kombination

Quelle:

oxp-rgb-hid.py
oxp-rgb-hid.rules

2) Konservative Legacy-Paketfamilie

Im alten Repo dokumentiert bzw. implementiert:

enable: 07 ff 05 00
level off: 07 ff fd 00 05 01
level 1: 07 ff fd 01 05 01
level 2: 07 ff fd 01 05 03
level 3: 07 ff fd 01 05 04
static mode: 07 ff fd 00 05 04
rainbow mode: 07 ff fd 01 05 04
preset range: 0x00..0x16
static color family: 07 ff fe RR GG BB ...

Diese Familie wurde jetzt in tools/superx_hidraw_rgb.py als referenzierbare Legacy-Hilfe übernommen.

3) Blockierter Deckel-/Logo-RGB-Pfad

DECKEL_RGB_STATUS.md sagt ziemlich klar:

Frostbay funktioniert
Keyboard-/internes RGB funktioniert laut damaligem Stand
Deckel-/Logo-RGB bleibt ungelöst
erfolglos getestet wurden:
- HID-Route
- WMI EC-Memory / WMBB method 6
- WMI CMS / WMBB method 4

Das ist wichtig, weil es die Theorie stärkt:

Nicht alles RGB hängt am gleichen Pfad.
Ein proprietärer Init-/Unlock-/Handshake-Schritt ist realistisch.

4) Frostbay-Reverse-Engineering ist weiter als nur ein vager Plan

Das alte Repo enthält bereits:

tools/frostbay-ble-control.py
tools/frostbay-ble-dump.py
tools/frostbay-native-test.sh
tools/oxp-frostbay-status.py
zusätzliche Diagnose-/Vergleichswerkzeuge

Das heißt: für Frostbay starten wir nicht bei null.

Einordnung für dein Gerät mit WS2812B-Ersatzstripes

Bekannte lokale Fakten:

Ersatzstripes sind WS2812B
du vermutest Anschluss RGB2

Das alte Repo hilft hier so:

Es bestätigt, dass ein OEM-/Vendor-RGB-Pfad auf dem Super X existiert.
Es liefert konkrete kleine Testframes statt blindem Raten.
Es beweist aber nicht, dass dein umgebauter Strip logisch 1:1 wie der damalige Zielpfad reagiert.

Darum bleibt die sichere Arbeitsregel:

alte Pakete erst dry-run / katalogisieren
nur kleine reversible Tests
Beobachtung mitloggen
OEM-Helper-/CompatLayerCT-Semantik weiter parallel auswerten

Konkrete Übernahmen in `SuperX-goes-Arch`

Bereits übernommen:

docs/safe-test-frames.md erweitert
tools/superx_hidraw_rgb.py kann Legacy-Pakete jetzt katalogisieren und dry-run erzeugen

Noch sinnvoll für später:

Frostbay-Tooling gezielt sichten und in ein eigenes tools/frostbay/-Layout überführen
udev-Regel-Entwurf für 1a86:1305 Interface 02
Vergleichsmatrix alt vs. neu: hidraw1, hidraw2, CompatLayerCT, Frostbay

Offene Vorsichtspunkte

"funktioniert" im alten Repo heißt nicht automatisch "funktioniert identisch auf deinem reparierten Strip"
das alte Repo trennt Keyboard-/internes RGB nicht immer perfekt sprachlich vom Deckel-/Logo-Pfad
für Repo-Erstellung auf git.nepharius.at fehlt hier aktuell gültige Authentifizierung; HTTPS-lesen geht, SSH-Schreiben gerade nicht

Nächster sinnvoller Schritt

Legacy-Pakete nur lokal dry-run prüfen
Frostbay-ZIP in ~/Downloads auswerten und mit altem Frostbay-Tooling abgleichen
dann ein sauber strukturiertes Repo-Layout für SuperX-goes-Arch weiter ausbauen

3.9 KiB Raw Permalink Blame History

Import-Notizen aus onexplayer-superxcontrol