SuperX Deckel-RGB Status (2026-05-11)

Kurzfazit

Der Deckel-/Logo-RGB-Pfad auf dem OneXPlayer Super X ist aktuell nicht gelöst. Frostbay und Keyboard-RGB funktionieren, aber der Deckel-RGB reagiert auf keinen der verifizierten Linux-Pfade.

Status: [blocked] proprietärer/unbekannter Control-Path

Was verifiziert funktioniert

Frostbay BLE-Steuerung inkl. Status/Recover
Keyboard-/internes RGB über 1a86:1305 Interface 02 (/dev/hidraw2)

Was getestet wurde (ohne Treffer für Deckel-RGB)

1) HID-Route

Device-Mapping zeigt nur 1a86:1305 (Keyboard K2445) als RGB-relevanten USB-HID Kandidaten
konservative und erweiterte Output-Report-Tests
Feature-Report-Tests (0x1a/0x1b/0x1c) mit readback/protocol checks
Ergebnis: kein sichtbarer Deckel-RGB-Effekt

2) WMI EC-Memory (`WMBB method 6`, `M04C(0xFE800400, off, val)`)

gezielte Kandidaten-Tests (0x50..0x60)
High-Range-Scan (0xE0..0xFF) mit Revert-by-default
spezielle Kandidaten um KBFG/SYSK/DIEL/DIEH (0xF0..0xF3)
Ergebnis: kein sichtbarer Deckel-RGB-Effekt

3) WMI CMS (`WMBB method 4`, `CMSW(addr, value)`)

eigener guarded Writer + Scan (0xF0..0xFF)
Ergebnis: kein sichtbarer Deckel-RGB-Effekt

ACPI-Hinweise

In DSDT.dsl ist WMBB als zentraler WMI-Dispatcher sichtbar:

Arg1=3: CMSR
Arg1=4: CMSW
Arg1=5: Read M049(0xFE800400, off)
Arg1=6: Write M04C(0xFE800400, off, val)

Getestet wurden die praktikablen Schreibpfade 4 und 6 ohne Deckel-RGB-Treffer.

Warum aktuell blockiert

Ohne native OneXConsole-Telemetrie (Windows) fehlt der proprietäre Kommando- oder Handshake-Pfad, der den Deckel-RGB wahrscheinlich initialisiert/entsperrt.

Nächste sinnvolle Schritte

Native Windows-Capture erneut aufsetzen (OneXConsole läuft stabil, BLE/HID trace mitschneiden)
One-Netbook Support mit technischem Testprotokoll kontaktieren
Falls Firmware-Dokumentation/SDK verfügbar: gezielte Implementierung statt weiterer Blind-Scans

2 KiB Raw Permalink Blame History