Skip to content

feat(Razer): Adding Support for 100 mouses - #45

Merged
snekxs merged 9 commits into
OpenMouse-Project:devfrom
viix0dev:dev
Aug 9, 2026
Merged

feat(Razer): Adding Support for 100 mouses#45
snekxs merged 9 commits into
OpenMouse-Project:devfrom
viix0dev:dev

Conversation

@viix0dev

Copy link
Copy Markdown
Contributor

Adds support for 100 Razer mouses.
Tested only with Razer Deathadder Essential (Needs more testing).
Primary implementation references:

Current supported-device list:
https://openrazer.github.io/

OpenRazer repository / current master device table:
https://github.com/openrazer/openrazer

Mouse driver:
https://github.com/openrazer/openrazer/blob/master/driver/razermouse_driver.c

Common report definitions:
https://github.com/openrazer/openrazer/blob/master/driver/razercommon.h

Chroma/common command constructors:
https://github.com/openrazer/openrazer/blob/master/driver/razerchromacommon.c

Mouse driver header / PID constants:
https://github.com/openrazer/openrazer/blob/master/driver/razermouse_driver.h

OpenRazer mouse-driver usage notes:
https://github.com/openrazer/openrazer/wiki/Using-the-mouse-driver

Implementation work was assisted with Claude Code & Codex (For Research)

Supported Mouses:
List: https://github.com/viix0dev/openmouse/blob/dev/src/devices/razer/devices.ts

Tests Results (211/211):

ℹ tests 211
ℹ suites 0
ℹ pass 211
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 3647.1993

@KuririmFestozo

Copy link
Copy Markdown

Tested this on a real Razer Viper V3 HyperSpeed (VID 1532 / PID 00B8) using the stock HyperSpeed receiver.

Most things seem to be working fine (battery, DPI read/write, lift-off distance, sleep timeout, etc).

I did find one issue with polling rate though. The current 0x00B8 profile inherits highRatePolling: true, which makes it use the extended polling command (0x40). The Viper V3 HyperSpeed rejects that command as unsupported.

I locally changed the entry to:

ts
[0x00b8, {
model: "Viper V3 HyperSpeed",
...VIPER_RECEIVER_WIRELESS,
highRatePolling: false,
maxDpi: DPI_FOCUS_PRO
}],

After that I tested:

  • 1000 → 500 Hz
  • 500 → 125 Hz
  • 125 → 1000 Hz

All three changes were accepted and correctly read back from the mouse afterward.

So highRatePolling: false looks like the correct setting for the Viper V3 HyperSpeed / PID 0x00B8.

Happy to send the full diagnostics JSON if useful.

@matthewgriffinSS

Copy link
Copy Markdown

viper-receiver transaction id looks wrong for the Viper Ultimate generation (hardware-confirmed)

Testing src/devices/razer/devices.ts against a real Razer Viper Ultimate (0x007b)
I hit a transaction-id mismatch.

The Viper Ultimate routes through viper-receiverMODERN_WIRED/MODERN_RECEIVER,
which assign transactionId: RAZER_TRANSACTION_ID (0x1f). But it only answers on
0x3f (your RAZER_TRANSACTION_ID_LEGACY):

  • Reading over native HID (node-hid) with 0x1f → no reply. With 0x3f
    firmware/DPI/polling/battery read back correctly (v1.05 / 5000 DPI / 1000 Hz / 93%).
  • Matches OpenRazer, which uses 0x3f for the whole 2019–2020 HyperSpeed-receiver
    generation (Viper Ultimate, DeathAdder V2 Pro, Naga Pro, Basilisk Ultimate,
    Lancehead/Mamba Wireless, …).

Since those PIDs are all verified: false, it's latent, nothing has exercised them.
The newer 0x1f models (Viper V2/V3 Pro) are correct, which is why they pass.

Suggested fix: give the older receiver generation 0x3f (i.e. _LEGACY) instead
of inheriting 0x1f from the shared base, and audit each receiver-family PID against
OpenRazer's transaction_id. (Minor: _LEGACY = 0x3f is a misleading name — 0x3f
is the middle generation; 0xff is the oldest.)

Note for the WebHID path / #47: on the Viper Ultimate dongle, Chrome exposes no
feature report on any interface (every collection is feat[none]; the Generic-Desktop-
Mouse interface's reports are stripped as "protected"), so sendFeatureReport fails
regardless of transaction id. I could only drive it via the native OS HID API, so this
model realistically needs the native/HAL transport, not WebHID. Happy to share the repro.

The stock HyperSpeed receiver rejects the extended polling command
(0x00/0x40) as unsupported and answers only the legacy divisor-of-1000
one, so every polling change failed its read-back.
@viix0dev

viix0dev commented Aug 9, 2026

Copy link
Copy Markdown
ContributorAuthor

@KuririmFestozo Yes, please send the diagnostics JSON.
I pushed a fixed version. you can test it

@viix0dev

Copy link
Copy Markdown
ContributorAuthor

@matthewgriffinSS I'm working on fixing it. it will be pushed soon.

A hardware report on the Viper Ultimate (1532:007b) found 0x1f silent
where 0x3f reads correctly. The cause was structural: transactionId was
a field on the transport presets, so it was inherited one wrong preset
produced 26 wrong products.
Audited every product against the id OpenRazer's firmware read selects.
26 were fixed.
@viix0dev

Copy link
Copy Markdown
ContributorAuthor

@matthewgriffinSS I’ve pushed a fix. could you retry it here and let me know if you’re still seeing the issue?
https://openmouse-sable.vercel.app/
This is a deployed version of my repo.

In some mouses like (Basilisk X HyperSpeed - tested on hardware) it returns 0x0b/0x85 with status 0x02 which makes the website
show the lift-off controls when the hardware doesn't support it so if you try to apply this setting it will return (failed: 0x01 was acknowledged and stored nothing, 0x02 was refused.)
@viix0dev

viix0dev commented Aug 9, 2026

Copy link
Copy Markdown
ContributorAuthor

Tests I ran with people (5/5):
Razer DeathAdder V3 Pro - works (tested with hardware)
Razer DeathAdder V2 X HyperSpeed - works (tested with hardware)
Razer Basilisk X HyperSpeed - works (tested with hardware)
Razer DeathAdder Essential - works (tested with hardware)
Razer DeathAdder V2 (wired) - works (tested with hardware)

@snekxs
snekxs merged commit 91a4427 into OpenMouse-Project:devAug 9, 2026
3 checks passed
@natic0309

Copy link
Copy Markdown

Selected device is not a supported control interface (DeathAdder V4 Pro (VID 0x1532 PID 0xbf; usage 0x1:0 feat[none] | usage 0x1:0 feat[none] | usage 0xc:1 feat[none]) · unknown (VID 0x1532 PID 0xbf; usage 0xc:1 feat[none])). Pick a vendor control interface (not a plain boot mouse). If this keeps failing, note the VID/PID from this message.

@viix0dev

Copy link
Copy Markdown
ContributorAuthor

@natic0309
it doesnt support WebHID only works via Native HAL( razer designed it this way ) so for now our web app wont support it

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

@viix0dev@KuririmFestozo@matthewgriffinSS@natic0309@snekxs