Repository navigation
razer: stop offering WebHID-inaccessible models (nativeOnly) - #2
Merged
Merged
Conversation
The DeathAdder V4 Pro (0xbe/0xbf) and the Viper Ultimate wireless receiver (0x007b) carry their control channel on a collection Chrome classifies as a plain mouse and strips feature reports from, so sendFeatureReport fails on every interface no matter how many are granted (confirmed on hardware with Synapse stopped; the dongle case was also reported on openmouse#45). The registry entries stay so the native HAL transport still has a config, but RAZER_REGISTRY_FILTERS now excludes nativeOnly products so the WebHID picker stops offering them as dead entries.
A previously granted nativeOnly device can still enumerate through navigator.hid.getDevices() (auto-reconnect, shared grants across origins), so isSupported must reject it regardless of the interface shape. This keeps the picker filter and the claim check consistent.
jazzstack
pushed a commit
that referenced
this pull request
Sep 9, 2026
…off-scale feat(atk): identify the A9 Mini + and add a continuous lift-off range
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The DeathAdder V4 Pro (0xbe wired / 0xbf receiver) and the Viper Ultimate wireless receiver (0x7b) carry their control channel on a HID collection Chrome classifies as a plain mouse and strips feature reports from.
sendFeatureReporttherefore fails on every interface, no matter how many collections are granted (confirmed on hardware with Synapse stopped; the receiver case was also reported on openmouse#45).This means the DeathAdder V4 Pro is not supported over WebHID and will not be: its control channel is only reachable through the native HAL (e.g. Synapse), so no amount of HID granting can make it work in the browser. The registry keeps a
nativeOnlyentry purely so the native HAL transport still has a config.Despite that, the WebHID picker offered these models as usable entries, so users picked a mouse that could never connect.
Change
nativeOnly: truein the registry (entries stay, so the native HAL transport still has a config).RAZER_REGISTRY_FILTERSnow excludesnativeOnlyproducts, sorequestDevice({ filters })stops offering them as dead entries.RazerHidClient.isSupportedrefusesnativeOnlymodels even when a previously granted device enumerates (e.g.getDevices()auto-reconnect, grants shared across origins).Verification
nativeOnlyproduct is still offered and none of thenativeOnlyones are.isSupportedtest asserts 0xbe is refused on both the mouse and vendor interface shapes.tsc --noEmitclean.