Attack Shark X11 (0x1d57:0xfa55 / 0xfa60): no controls via Desktop or webapp + Bridge

[snekxs]

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

1. Connect Attack Shark X11 (wired and/or 2.4 GHz receiver)
2. Open OpenMouse Desktop, and webapp via Bridge
3. 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.

[snekxs]

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]

AttackSharkmouse24GHzreceiverhardwaretest(1).json

openmouse-1d57-fa60-2026-10-04-08-48-28.json

Dropping these if there's any help

[sLimbutin]

[snekxs]

Root cause found from the Bridge diagnostic the reporter posted: the rebuilt config collection carries no report sizes, and X11_REBUILT_CONFIG_MODELS only allowed the Delux M600 Pro (0x20), so a genuine X11 (model 0x55) stayed status-only even over Bridge.

#174 enables 0x55 on 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]

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]

Changing polling rate seems to work tho.

[sLimbutin]

openmouse-bridge.2026-10-06.log