Repository navigation
Attack Shark X11 (0x1d57:0xfa55 / 0xfa60): no controls via Desktop or webapp + Bridge #161
Description
Bug Description
Reported in Discord by sLimbutin: no controls over Attack Shark X11, tested both Desktop and webapp via Bridge. Device is detected (shows up) but no settings are controllable from either path.
Current driver state (for context)
- Driver:
src/drivers/attackshark/hid.ts - 0x1d57 family (R1/X11, PIDs 0xfa55 wired / 0xfa60 receiver, model id 0x55 = X11) is native-only for config: browser WebHID alone intentionally shows status-only (
needs a native driver), full polling (0x06) + DPI stages (0x04) go through the Bridge / Desktop hidapi adapter. - Hardware-verified sibling on the same receiver: Delux M600 Pro (
docs/delux-m600-pro-testing.md, Linux, 2026-09-24, polling + DPI writes measured). Genuine X11 (model id 0x55) has mock unit tests only (hid.test.ts) — no hardware testing doc exists. - So a report of no controls even via native paths suggests either a regression in the native path, a PID/collection variant (e.g. 0x25a7 direct-protocol X11), or a model-id mismatch.
Steps to Reproduce
- Connect Attack Shark X11 (wired and/or 2.4 GHz receiver)
- Open OpenMouse Desktop, and webapp via Bridge
- Observe: device appears but exposes no controls (screenshots in Discord thread)
Expected Behavior
- Native paths (Desktop / webapp + Bridge) should expose polling (125/250/500/1000 Hz) + 6-stage DPI editor + battery for model 0x55, same as the tested Delux sibling.
Needed to debug
- OS + Desktop app version + Bridge version
- VID:PID as shown in the device picker (wired vs receiver) + wired/wireless mode tested
- Bridge/Desktop logs for connect + readStatus (does it claim attackshark family? what displayName? any 0x04/0x06 write errors?)
- Receiver message byte 1 (model id — is it 0x55, or a new X11 variant like SE/Pro?)
- Screenshots already posted in Discord (please attach here)
Environment
- Reporter: sLimbutin via Discord
- Paths tested: Desktop app + webapp via Bridge (both fail)
- Browser-only failure is expected by design; native-path failure is the bug.
Activity
snekxs commentedon Oct 3, 2026
Update from Discord (snekxs): reporter is running it through both the Bridge and the Desktop app — both native paths give no controls, not just browser WebHID. So this is a native-path failure, not the expected browser status-only limitation.
sLimbutin commentedon Oct 4, 2026
AttackSharkmouse24GHzreceiverhardwaretest(1).json
openmouse-1d57-fa60-2026-10-04-08-48-28.json
Dropping these if there's any help
sLimbutin commentedon Oct 4, 2026
snekxs commentedon Oct 6, 2026
Root cause found from the Bridge diagnostic the reporter posted: the rebuilt config collection carries no report sizes, and
X11_REBUILT_CONFIG_MODELSonly allowed the Delux M600 Pro (0x20), so a genuine X11 (model0x55) stayed status-only even over Bridge.#174 enables
0x55on that path — same receiver, protocol and transport as the verified M600 Pro, resolving to the receiver's 56-byte DPI frame. R1/X3/X6 stay read-only until their frame shapes are established.@sLimbutin — could you build this branch and confirm DPI, polling and battery on the X11? Keeping this open until it's confirmed on hardware.
sLimbutin commentedon Oct 6, 2026
AttackSharkX11hardwaretest.json
Tried after merge. Polling rate seems to be only setting that can be changed, however when testing mouse hardware polling rate is not reported to OpenMouse.
{ "key": "sampling", "label": "Polling rate sampling", "status": "skip", "detail": "avg 64 Hz vs reported 1000 Hz — dropout or rate mismatch detected, so the sample is not counted as a failure." },sLimbutin commentedon Oct 6, 2026
Changing polling rate seems to work tho.
sLimbutin commentedon Oct 6, 2026
openmouse-bridge.2026-10-06.log
sLimbutin commentedon Oct 6, 2026
fix(attackshark): enable the X11 on the rebuilt Bridge config path
snekxs commentedon Oct 9, 2026
Update on what's changed since your last confirmation (DPI + polling controls showing):
Fixed since your logs (committed, pending release):
native-hid: theAttack Shark X11 native DPI control is not implemented yeterror from your 2026-10-06 log is gone. Polling-only requests keep the verified direct feature-report path; anything with DPI now goes throughAttackSharkHidClient's 0x04 six-stage path, preserving untouched stages. Protocol pin bumpedv0.10.0→v0.30.0(includes fix(attackshark): enable the X11 on the rebuilt Bridge config path #174).dpi 0, which is the normal state of the X11's write-only channel before the first write. It now also shows when a DPI stage editor is present.0xfa60/0xfa55, so future hardware-test reports resolve to X11 / Needs Bridge instead of Delux M800 Mini (yourAttackSharkX11hardwaretest.jsonmatched M800 Mini by PID).docs/attackshark-x11-testing.mdrecording your Bridge diagnostic, the fix(attackshark): enable the X11 on the rebuilt Bridge config path #174 enablement, and your post-merge results.To close this out, still needed on a build with the above:
0xfa55) check, if you have the cable handy — only the receiver has been exercised.faillines in the hardware test are by firmware design (the X11 exposes no read-back commands; the driver reports cached/default stages), not regressions.Once 1 (and ideally 2) confirm, this can be closed.
feat(wallhack): add M-001 buttons, macros, rotation, scan mode and DP…