pandoras-box/umbra
8
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

UMBRA-9: Add DeviceSpecs for the Abyssus line (6 PIDs) #20

Merged
David merged 2 commits from feat/abyssus-line-devicespecs-UMBRA-9 into main 2026-06-07 05:23:56 +02:00
Conversation 0 Commits 2 Files changed 9 +358
David commented 2026-06-06 16:28:00 +02:00
Owner
Copy link

UMBRA-9: Add DeviceSpecs for the Abyssus line (6 PIDs)

Registers all six Abyssus PIDs from OpenRazer's razermouse_driver.h as DeviceSpecs, each in its own crates/umbra-hid/src/models/<model>.rs file and wired into the SUPPORTED table, so umbra info recognizes the device and exposes whatever DPI / poll-rate / lighting features the OpenRazer driver actually wires up for it. All VID 0x1532.

Per-command transaction IDs, poll rates, DPI command path, lighting zones and effect kinds were read branch-by-branch off the live razermouse_driver.c (downloaded from OpenRazer master), not assumed. Features with no umbra command builder are declared None with a doc comment per the existing precedents.

PID Model DPI Lighting Notes
0x0020 Razer Abyssus 1800 None None Legacy 1-byte DPI path + on/off logo LED, neither built by umbra
0x0042 Razer Abyssus 2014 None None Driver wires no DPI path (write_dpi -EINVAL); on/off logo LED only
0x005B Razer Abyssus V2 5000 None Modern DPI on 0xFF; classic-LED Chroma path (mirrors DeathAdder Chroma), not built by umbra
0x005E Razer Abyssus 2000 2000 None Modern short/short DPI on 0xFF; on/off logo LED only
0x006A Razer Abyssus Elite (D.Va Edition) 7200 Logo (1 zone), full effects @ 0x3f Extended-matrix; logo LED drives the Chroma underglow
0x006B Razer Abyssus Essential 7200 Logo (1 zone), full effects @ 0x3f Extended-matrix Chroma

All six run firmware / serial / poll on 0xFF (standard misc path) and are wired-only (no battery, no idle). The Elite and Essential expose the full extended-matrix effect set (None / Static / Spectrum / Reactive / Breathing single, dual, random).

DPI maxima, where modelled, are sensor-derived assumptions (the driver does not clamp DPI) and documented as such in each file's doc comment.

Notes / deviations from the issue spec

  • The issue's stated assumption that PID 0x005E (Abyssus 2000) would have DPI None under the legacy-builder gap did not hold against the driver: 0x005E uses the modern razer_chroma_misc_set_dpi_xy path (not the byte path), which umbra builds. Per the acceptance criteria ("taken from the matching branch, not assumed") it is modelled with DPI max 2000. The byte-path / no-DPI assumption does hold for 0x0020 and 0x0042.
  • The issue table notes V2 as "Chroma logo", but the driver drives the V2's scroll and logo zones through the classic-LED set_led_state / set_led_rgb / set_led_effect path, which umbra has no builder for, so lighting is declared None (same treatment as DeathAdder Chroma 0x0043).

Verification

  • cargo test --package umbra-hid --no-default-features (protocol tests) passes, including the new every_abyssus_line_pid_is_registered test (25 passed).
  • cargo fmt --check clean.
  • cargo clippy is clean for this change. Note: three pre-existing doc_lazy_continuation clippy errors in untouched basilisk_* files surface under the newer local toolchain (rustc 1.94.0) but not under CI's pinned rust-builder-glibc image; verified they also fire on clean main and are unrelated to this PR.

#UMBRA-9

## UMBRA-9: Add DeviceSpecs for the Abyssus line (6 PIDs) Registers all six Abyssus PIDs from OpenRazer's `razermouse_driver.h` as `DeviceSpec`s, each in its own `crates/umbra-hid/src/models/<model>.rs` file and wired into the `SUPPORTED` table, so `umbra info` recognizes the device and exposes whatever DPI / poll-rate / lighting features the OpenRazer driver actually wires up for it. All VID `0x1532`. Per-command transaction IDs, poll rates, DPI command path, lighting zones and effect kinds were read branch-by-branch off the live `razermouse_driver.c` (downloaded from OpenRazer master), not assumed. Features with no umbra command builder are declared `None` with a doc comment per the existing precedents. | PID | Model | DPI | Lighting | Notes | |--------|----------------------------------|------|----------------------------|-------| | 0x0020 | Razer Abyssus 1800 | None | None | Legacy 1-byte DPI path + on/off logo LED, neither built by umbra | | 0x0042 | Razer Abyssus 2014 | None | None | Driver wires no DPI path (write_dpi `-EINVAL`); on/off logo LED only | | 0x005B | Razer Abyssus V2 | 5000 | None | Modern DPI on 0xFF; classic-LED Chroma path (mirrors DeathAdder Chroma), not built by umbra | | 0x005E | Razer Abyssus 2000 | 2000 | None | Modern short/short DPI on 0xFF; on/off logo LED only | | 0x006A | Razer Abyssus Elite (D.Va Edition) | 7200 | Logo (1 zone), full effects @ 0x3f | Extended-matrix; logo LED drives the Chroma underglow | | 0x006B | Razer Abyssus Essential | 7200 | Logo (1 zone), full effects @ 0x3f | Extended-matrix Chroma | All six run firmware / serial / poll on `0xFF` (standard misc path) and are wired-only (no battery, no idle). The Elite and Essential expose the full extended-matrix effect set (None / Static / Spectrum / Reactive / Breathing single, dual, random). DPI maxima, where modelled, are sensor-derived assumptions (the driver does not clamp DPI) and documented as such in each file's doc comment. ### Notes / deviations from the issue spec - The issue's stated assumption that PID `0x005E` (Abyssus 2000) would have DPI `None` under the legacy-builder gap did not hold against the driver: `0x005E` uses the modern `razer_chroma_misc_set_dpi_xy` path (not the byte path), which umbra builds. Per the acceptance criteria ("taken from the matching branch, not assumed") it is modelled with DPI max 2000. The byte-path / no-DPI assumption does hold for `0x0020` and `0x0042`. - The issue table notes V2 as "Chroma logo", but the driver drives the V2's scroll and logo zones through the classic-LED `set_led_state` / `set_led_rgb` / `set_led_effect` path, which umbra has no builder for, so lighting is declared `None` (same treatment as DeathAdder Chroma `0x0043`). ### Verification - `cargo test --package umbra-hid --no-default-features` (protocol tests) passes, including the new `every_abyssus_line_pid_is_registered` test (25 passed). - `cargo fmt --check` clean. - `cargo clippy` is clean for this change. Note: three pre-existing `doc_lazy_continuation` clippy errors in untouched `basilisk_*` files surface under the newer local toolchain (rustc 1.94.0) but not under CI's pinned `rust-builder-glibc` image; verified they also fire on clean `main` and are unrelated to this PR. #UMBRA-9
feat(umbra-hid): add DeviceSpecs for the Abyssus line
Some checks failed
Check / fmt + clippy + build + tests (pull_request) Failing after 4s
Details
9f1f328308 
Register all six Abyssus PIDs from OpenRazer's razermouse_driver.h as DeviceSpecs, each in its own models/<model>.rs file and wired into the SUPPORTED table so umbra info recognizes the device.

Per-command transaction IDs, poll rates, DPI paths, lighting zones and effect kinds are read branch-by-branch off razermouse_driver.c:

- Abyssus 1800 (0x0020): firmware/serial/poll on 0xFF. DPI uses the legacy 1-byte path and lighting is an on/off logo LED, neither of which umbra builds, so both are None.
- Abyssus 2014 (0x0042): firmware/serial/poll on 0xFF. The driver wires no DPI path (write_dpi falls through to -EINVAL) and only an on/off logo LED, so DPI and lighting are None.
- Abyssus 2000 (0x005E): firmware/serial/dpi/poll on 0xFF, modern short/short DPI path (max 2000, sensor-derived). On/off logo LED only, so lighting is None.
- Abyssus V2 (0x005B): firmware/serial/dpi/poll on 0xFF, modern DPI path (max 5000, sensor-derived). Lighting is the classic-LED Chroma path (set_led_state/rgb/effect), which umbra does not build, so lighting is None (mirrors DeathAdder Chroma).
- Abyssus Elite D.Va Edition (0x006A) and Abyssus Essential (0x006B): firmware/serial/dpi/poll on 0xFF, modern DPI path (max 7200, sensor-derived). Extended-matrix single logo zone on 0x3f exposing the full effect set (None/Static/Spectrum/Reactive/Breathing single, dual, random).

DPI maxima are sensor-derived assumptions (the driver does not clamp DPI) and documented as such in each file's doc comment. Registration and per-feature txn/zone/effect mapping are covered by a new every_abyssus_line_pid_is_registered test over models::lookup, and the six devices are added to the README supported-devices table.

#UMBRA-9
Merge remote-tracking branch 'origin/main' into feat/abyssus-line-devicespecs-UMBRA-9
All checks were successful
Check / fmt + clippy + build + tests (pull_request) Successful in 54s
Details
Create release / Create release from merged PR (pull_request) Has been skipped
Details
87f17da646 
# Conflicts:
#	crates/umbra-hid/tests/protocol.rs
David merged commit 5c9b4da9ea into main 2026-06-07 05:23:56 +02:00
David deleted branch feat/abyssus-line-devicespecs-UMBRA-9 2026-06-07 05:23:57 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pandoras-box/umbra!20
No description provided.