OpenSynapse Viper V3 Pro SE r4 (2026-10-27)

中文

修复 Razer Viper V3 Pro SE 无线（1532:00DF）设备页「点轮询率保存后 DPI 看起来被改了」的问题。

先说结论：你的 DPI 从来没被改。 视频里顶部摘要全程是 1600 x 1600 DPI，关掉浮层后 X/Y 也都是 1600。

真实原因是一条 UI 连锁反应：

1. 「保存」按钮的可用状态绑在 CanEditPolling 上，而它包含"写入中"判断 —— 所以点下去的瞬间按钮自己把自己禁用了。
2. 按钮一禁用就失去焦点，WinUI 把焦点交给焦点链上的下一个控件：DPI 的 X 输入框。
3. DPI 输入框是紧凑微调器，一拿到焦点就展开上下箭头浮层，横着盖住 Y 输入框最左边的数字。
4. Y 的 1600 首位 1 被盖住，屏幕上只剩 600，看起来就像 DPI 变成了 500/600。

所以这是遮挡造成的错觉，不是轮询率写入串到了 DPI。顺带一提，同一个设备页上的空闲超时、低电量阈值、充电上限、滚轮模式等「保存」按钮都有同样的问题，点了都会跳焦点。

修复：写入期间不再让这些按钮自我禁用（重复点击本来就有内部守卫挡着），焦点因此不会跳走，输入框在写入期间仍然禁用。

注意：本包同时包含 main 上对 HID 响应路由的修正（34f64b6），r3 那个包是旧提交构建的，没有这个修正。r3 之后你反馈轮询率读写已经正常，那个结论不受影响。

请完全退出正在运行的 OpenSynapse（包括托盘），下载本包解压运行，然后复测：切到 500 Hz 点保存，轮询率应显示 500 Hz，DPI 仍应是 1600 x 1600 且 Y 输入框不再被浮层遮住。此包为自包含测试包，未在 00DF 实机验证（本机只有 Viper V3 HyperSpeed 00B8）。

SHA-256：BE58B5507EAFE6BAF47E089489C57766FB04B4854C70ADA71067F39F176F9DF7

English

Fixes the "DPI appears to change after saving the polling rate" glitch on the Razer Viper V3 Pro SE Wireless (1532:00DF) device page.

Your DPI was never changed. The summary line stays at 1600 x 1600 DPI throughout the video, and X/Y both read 1600 once the flyout closes.

What actually happens is a UI chain reaction:

1. The save button's enabled state is bound to CanEditPolling, which includes the busy check — so the button disables itself the moment you click it.
2. A disabled button loses focus, and WinUI hands focus to the next control on the tab chain: the DPI X input.
3. That input is a compact spin button, and a focused one pops its chevron flyout, which covers the left edge of the Y input.
4. The leading 1 of Y's 1600 is hidden, leaving 600 on screen and looking like the DPI changed.

So it was a rendering illusion, not the polling write landing on the DPI. The same thing happens with the idle timeout, low battery threshold, charge limiter and scroll mode save buttons on that page.

Fix: those buttons no longer turn themselves off while a write runs (a second click was already blocked internally), so focus never moves away. The inputs still get disabled during the write.

Note: this build also carries the HID response routing fix from main (34f64b6); the r3 package was built from an older commit and does not have it. That does not change your report that polling read and write now work.

Fully quit OpenSynapse (including the tray), unpack this build and run it, then retest: pick 500 Hz and save — the polling rate should read 500 Hz and the DPI should still read 1600 x 1600 with the Y input no longer covered. This is a self-contained pre-release test build and has not been verified on 00DF hardware (only a Viper V3 HyperSpeed 00B8 is available here).

SHA-256: BE58B5507EAFE6BAF47E089489C57766FB04B4854C70ADA71067F39F176F9DF7

OpenSynapse Leviathan V2 X (054A) r1 (2026-10-27)

中文

修复 Razer Leviathan V2 X（1532:054A）设备页显示「控制通道未解析 / 查询失败」的问题。

根因是校验和，不是协议。 用户日志里设备其实每次都正确应答了：

attempt 1: response validation failed, status=0x02, txn=0x08 (want 0x08),
  class=0x00 (want 0x00), command=0x81 (want 0x81), len=2 (want 2),
  crc=0x8D, computed=0x85

状态、transaction、class、command、长度全部匹配，只有校验和差一个字节。而且这个差值精确等于 transaction id（固件读 0x08、序列号读 0x09、亮度读 0x0A，三次都吻合）——054A 把 transaction id 也算进了响应校验和，而通用范围不含它。每一次探测都被判成"校验失败"，通道自然永远解析不出来。

官方雷云中间件从不校验响应校验和（只比对 transaction、class、command 和状态），所以官方不会碰到这个差异。现在只对 054A 接受含 transaction 的校验和范围，其它设备保持不变。

另外修了两个同一台设备上发现的问题：

• 音频页的低音和自定义 EQ 写入原本发到 profile 1、回读却读 profile 0，回读必然对不上。官方 1354 面板路径读写都在 profile 0，profile 1 属于 Broadcaster 广播路径，声霸不走那条路。现在读写统一 profile 0。
• 设备通道探测时的亮度探针发的是 region 0，而 054A 没有 All region，固件不认。正常读写路径本来就会先读 region 列表取第一个，只有探测这条路漏了，现已跳过。

请这样复测：

1. 完全退出正在运行的 OpenSynapse（包括托盘），解压本包运行。
2. 设备页应能看到 Leviathan V2 X，点进设备页后诊断页不再显示「控制通道未解析」。
3. 如果能读到，请顺便看一眼低音和 EQ 预设的读数是否合理；先只读，不要急着写入，确认读数正常后再改一个值看回读。

如果仍有问题，请重新导出诊断信息和日志。

本包为自包含测试包。未在 054A 实机验证——根因由用户日志的三组真实数值确定，但修复本身尚未在该设备上跑过。

SHA-256：88FDA2B3B5932865B58C75F8F8F0F2543C2D617BB7F8E6A535F1EA0753E8CAF2

English

Fixes the "control channel not resolved / query failed" state on the Razer Leviathan V2 X (1532:054A) device page.

The checksum was wrong, not the protocol. The device log shows it answered every probe correctly:

attempt 1: response validation failed, status=0x02, txn=0x08 (want 0x08),
  class=0x00 (want 0x00), command=0x81 (want 0x81), len=2 (want 2),
  crc=0x8D, computed=0x85

Status, transaction, class, command and length all match — only the checksum differs, and it differs by exactly the transaction id (0x08 for the firmware read, 0x09 for the serial, 0x0A for the brightness; all three agree). The soundbar folds the transaction id into the checksum of its replies, while the shared range starts one byte later. Every probe was therefore rejected as invalid and the channel could never be opened.

Razer's own middleware never checks the response checksum (it compares transaction, class, command and status only), so it never runs into this. The transaction-folded range is now accepted for 054A only; every other device keeps the shared one.

Two more problems found on the same device:

• The audio page wrote bass and custom EQ to profile 1 but read back profile 0, so the readback could never match. The official 1354 panel path reads and writes profile 0; profile 1 belongs to the Broadcaster broadcast path, which the soundbar does not use.
• The brightness probe asked for region 0, which is not a region this firmware has. The normal read and write path already reads the region list first, so only the probe was wrong.

How to retest:

1. Fully quit OpenSynapse (including the tray), unpack this build and run it.
2. Leviathan V2 X should appear on the device page, and the diagnostics page must no longer say "control channel not resolved".
3. If it reads, check the bass and EQ preset values. Read first, do not write yet — confirm the numbers look right before changing one and watching the readback.

If it still fails, please send the diagnostics and the log again.

This is a self-contained pre-release test build. It has not been verified on 054A hardware — the root cause is pinned by three real numbers in the device log, but the fix itself has not run on that device yet.

SHA-256: 88FDA2B3B5932865B58C75F8F8F0F2543C2D617BB7F8E6A535F1EA0753E8CAF2

Leviathan V2 X 灯带效果 / Light-strip effects (r2)

Leviathan V2 X (054A) 灯带效果测试包 / Light-strip effects test build

这个包补上了 054A 的灯带效果，r1 只有亮度/回读修复，所以旧包里看不到模式切换。

本版新增

• 关闭 / Off
• 静态 / Static
• 双色呼吸 / Breathing (dual color)
• 光谱循环 / Spectrum
• 波浪 / Wave

打开设备页时会先读取当前效果；亮度、EQ、输入源逻辑不变。

测试方法

1. 托盘退出旧版，解压完整 ZIP 后运行 OpenSynapse.App.exe。
2. 打开 Leviathan V2 X 设备页，在灯光卡里依次切换上面的效果并应用。
3. 每次切换后刷新设备页，确认当前效果能读回。
4. 如果效果不变或页面报错，请发 %LOCALAPPDATA%\A1mAssist\OpenSynapse\logs\opensynapse.log。

注意

• 未在 054A 实机上验证效果写入/回读，需要用户实测确认。
• 未开放的官方效果：Starlite、CustomFrame、Fire、AudioMeter、Wheel；这些需要额外参数语义，本包没有放空控件。

SHA-256: 5488D4F324B1188410ED57C382FA2D5F6BD8E65873D5FCE582B551668C971860

---

This build adds the soundbar light-strip effects. r1 only fixed brightness/readback, which is why the mode selector was still missing. Effects: Off, Static, Breathing (dual color), Spectrum, Wave. The page reads the current effect on load. Brightness, EQ and input-source behavior are unchanged. Not hardware-verified on a 054A unit; please test and report. SHA-256 is above.

OpenSynapse Blade fan speed ceiling (2026-10-27)

中文

修复 Blade 系列风扇转速上限偏低的问题（#23）。

先说结论：你看到的 5100 RPM 我们之前确实给不了，但原因不是固件不支持，而是我们自己的上限设错了。

我们把固定转速卡在 5000 RPM。这个数字当初是一次性写进代码的，没有任何出处——既不是官方数值，也没有实测依据。而它还顺带砍掉了几个机型实测能读回的更高转速。

查了雷云官方 middleware bundle 之后，真相是这样：

• 官方写风扇速度用的是 rpm / 100，和我们发出的报文完全一致（同一字节布局）。
• 每个机型自己的 bundle 都声明了它的性能模式用到多少转速。灵刃 16 (2025) 的 Performance 和 Hyperboost 模式最高 5400 RPM；灵刃 15 (2019) 和灵刃 16 (2023) 到 5300 RPM；灵刃 14 (2022) 也是 5400 RPM。

也就是说固件本来就接受这些转速，是我们的滑块和写入校验提前拦住了。

改动：

• 每个开放固定风扇的机型，现在都带上自己 bundle 声明的上限（灵刃 16 (2025) 5400、灵刃 15 (2019) 5300、灵刃 16 (2023) 5300、灵刃 14 (2022) 5400，其余 Blade 14/16/18 系列 5400）。
• 手动风扇曲线的点位上限、曲线图纵轴刻度、默认曲线最高点同步放开到 5400。
• 之前被 5000 卡住的读回上限也一并修正：灵刃 15 (2019) 和灵刃 16 (2023) 现在能正常读回 5300。

请复测：完全退出正在运行的 OpenSynapse（包括托盘），解压本包运行，在设备页选「固定风扇转速」，输入框现在可以填到 5400；手动风扇曲线里也能把点位拉到 5400。应用后麻烦确认一下设备页显示的目标转速和实际转速计是否一致。如果写入被固件拒绝，请把 %LOCALAPPDATA%\OpenSynapse\logs\opensynapse.log 发我。

此包为自包含测试包，未在 02C6 实机验证写入 5400（本机只有 Blade 16 2025 02C6 但未做风扇写入实测）；读回路径和协议编码有测试覆盖。

SHA-256：6580052C5285E6AF5B9B7D170087FD2ABA3DE2B0125365F47B014B71FC071D2F

English

Fixes the Blade fan-speed ceiling being lower than the hardware allows (#23).

Your 5100 RPM was genuinely out of reach before, but not because the firmware refuses it. Our own limit was wrong: it stopped at 5000 RPM, a number written into the code in one commit with no source behind it. It also cut off the higher speeds some models demonstrably read back.

The official middleware bundle settles it:

• The official code writes the fan speed as rpm / 100, exactly the value this protocol already sends.
• Each model's bundle declares the speeds its own performance modes use. The Blade 16 (2025) runs up to 5400 RPM in Performance and Hyperboost, the Blade 15 (2019) and Blade 16 (2023) reach 5300 RPM, and the Blade 14 (2022) also reaches 5400 RPM.

The firmware already accepted these speeds; our slider and write guard stopped them first.

What changed:

• Every model that accepts a fixed target now carries the ceiling its own bundle declares (Blade 16 (2025) 5400, Blade 15 (2019) and Blade 16 (2023) 5300, Blade 14 (2022) 5400, and the other Blade 14/16/18 models 5400).
• The manual fan-curve point ceiling, the curve plot's axis ticks and the default curve follow suit.
• The read-back ceiling that 5000 used to clip is fixed too: the Blade 15 (2019) and Blade 16 (2023) now read their stored 5300 RPM back correctly.

Please retest: fully quit OpenSynapse (including the tray), unpack this build and run it, then pick "Fixed fan speed" on the device page — the field now accepts up to 5400 — and the manual fan curve accepts 5400 points too. After applying, please confirm the target and the tachometers agree. If the firmware rejects a write, send %LOCALAPPDATA%\OpenSynapse\logs\opensynapse.log.

This is a self-contained pre-release test build and a 5400 RPM write has not been verified on 02C6 hardware; the read-back path and the protocol encoding are covered by tests.

SHA-256: 6580052C5285E6AF5B9B7D170087FD2ABA3DE2B0125365F47B014B71FC071D2F

OpenSynapse Kraken V4 lighting r5 (2026-10-27)

中文

修复 Kraken V4 灯光点了没反应 的问题。

根因：我们的报文格式错了，固件把每一帧都丢掉了。

之前我们参考 OpenRGB 写的报文，但重新对了雷蛇官方产品包里的实现（Kraken V4 属于官方的 "Billie" 耳机系列），发现有两处致命偏差：

1. 缺少校验和。官方在第 62 字节放的是前 62 字节的 XOR 校验和，我们填的是 0。固件会校验这一项，对不上就直接丢弃整帧 —— 所以界面显示"应用成功"，灯环却毫无反应。
2. 命令号不对。写颜色要用 Set Chroma Frame（class 0x0F / command 0x10），我们之前用的是 0x0F / 0x03（那是"设置特效 ID"用的，只带 1 字节）。设置"关闭/静态/波浪"要走 Set Chroma Effect（0x00 / 0xC1），命令头还要带完整的 C0 01 01 三字节。

现在四个帧（效果、颜色帧、关闭、波浪）与官方实现逐字节一致，包括校验和。测试里直接锁定了官方的十六进制帧，防止以后再改错。

另外这次给灯光写入加了日志：以后点「应用灯效」时，日志里会记录实际发出的每一帧（[kraken-lighting]），不会再出现"完全看不出发生了什么"的情况。

你的日志帮我确认的事

日志很清楚，先说两条你可能会关心的：

• 你机器上同时插着两个身份：056B（USB-C 直连，产品名 Razer Kraken V4 USB - Chat）和 056C（2.4 GHz 接收器，产品名 Razer Kraken V4 - Chat）。两个都在日志里。
• 音频页找不到它，是因为它的 feature 接口只有 9 字节，不是我们程序需要的那种长度。这是硬件决定的，电量/EQ/麦克风都要靠那个接口，所以这三项做不了。

2.4 GHz 的灯光仍然没有，这次我查清楚了原因：雷蛇官方对 2.4G 接收器（AudioBillieT1Dongle）只实现了 OLED 屏相关功能，没有任何灯光写入。所以这不是我们偷懒，是官方自己也没做。要用灯光请用 USB-C 直连。

r5 测试包

OpenSynapse-issue16-r5-20261027.zip（Pre-release，自包含，不需要装 .NET）

SHA-256：CB4EE3B5FAC3BFA9B6C3D4CAF98B652B7083E6AEECD26496DA72888A7FAF922C

请这样测：

1. 托盘退出旧版 → 解压 r5 到新目录
2. USB-C 线直连（不要用 2.4G 接收器）
3. 设备页 → Razer Kraken V4 (Wired) → 灯光卡选「静态颜色」→ 挑个明显的颜色 → 「应用灯效」
4. 看耳罩灯环有没有变
5. 顺便试「关闭」和「波浪」
6. 如果还是没反应，发日志给我（路径在上一条回复里），这次日志里会有 [kraken-lighting] 记录，能直接看出帧有没有发出去

986 个测试通过，Release 自包含发布成功。这个包依然没有在 Kraken V4 实机验证过 —— 报文是照官方实现逐字节对齐的，但固件认不认，还得靠你试这一回。

English

Fixes the Kraken V4 lighting that never changed.

Root cause: our frames were malformed, so the firmware dropped every one of them.

We had based the frames on OpenRGB. Re-checking against Razer's own product bundle (the Kraken V4 belongs to the vendor's "Billie" headset family) showed two fatal differences:

1. No checksum. The firmware expects an XOR of bytes 0..61 in byte 62; we wrote 0. The firmware verifies it and drops the whole frame on a mismatch — which is why the UI reported success while the ring stayed dark.
2. Wrong command ids. Writing colours needs Set Chroma Frame (class 0x0F, command 0x10); we used 0x0F / 0x03, which is "set effect id" and carries a single byte. Setting off/static/wave goes through Set Chroma Effect (0x00 / 0xC1), whose command header is the full three bytes C0 01 01.

All four frames (effect, colour frame, off, wave) now match the vendor implementation byte for byte, checksum included. The test pins the vendor's hex frames so the format cannot silently drift again.

The lighting write also records the frame it sent, so a silent failure is now visible in the log as [kraken-lighting].

What your log settled

• Two identities are plugged in at once: 056B (USB-C, Razer Kraken V4 USB - Chat) and 056C (2.4 GHz receiver, Razer Kraken V4 - Chat). Both appear in the log.
• The audio page cannot find it because its feature interface is 9 bytes long, not the length our protocol needs. That is fixed by the hardware, so battery, EQ and microphone are not reachable.

2.4 GHz lighting is still absent, and now we know why: Razer ships no lighting writes at all for the dongle (AudioBillieT1Dongle only implements OLED functions). Use the USB-C cable for lighting.

r5 test build

OpenSynapse-issue16-r5-20261027.zip (Pre-release, self-contained, no .NET needed)

SHA-256: CB4EE3B5FAC3BFA9B6C3D4CAF98B652B7083E6AEECD26496DA72888A7FAF922C

How to test:

1. Quit the old build from the tray, unpack r5 into a new folder
2. Connect over USB-C (not the 2.4 GHz receiver)
3. Device page → Razer Kraken V4 (Wired) → lighting card → Static → pick an obvious colour → Apply
4. Watch the earcup ring
5. Try off and wave as well
6. If nothing happens, send the log (path from my previous reply) — it now contains [kraken-lighting] lines showing exactly which frames went out

986 tests pass, Release self-contained publish succeeded. This build is still unverified on Kraken V4 hardware — the frames are aligned byte for byte with the vendor implementation, but whether the firmware accepts them is what this round will tell us.

OpenSynapse Kraken V4 detection r4 (2026-10-27)

中文

修复 v1.6.0 里 Razer Kraken V4 完全不显示 的问题。

这是我们上一版的回归，不是你的耳机或驱动的问题。 你在 10-26 测 r3 时是有线的能正常显示的，v1.6.0 之后就没了 —— 时间点正好对得上。

原因

10-26 那天我们把 Kraken 系列的灯光卡从「灯光页」搬到了「音频页」，为了消除同一台耳机在两个页面各出现一行的重复。判断条件写的是"这个型号在音频页名单里就搬过去"。

但音频页是靠 91 字节 feature 接口来发现设备的，而 Kraken V4 只有 64 字节的 FF14:0001 接口（你之前发的日志里写得很清楚：out=64 in=64，没有 feature=91）。于是：

• 音频页永远选不中 Kraken V4 → 音频页里没有它
• 灯光页又因为"它在音频页名单里"而不生成那一行 → 灯光页里也没有它

两个页面都不显示，这台耳机就整个消失了。

修复

灯光卡只有在这台设备真的具备 91 字节 feature 接口时才搬进音频页。Kraken V4 不具备，所以它的灯光卡回到自己的一行。

修好后：用 USB-C 线直连时，设备页会出现 Razer Kraken V4 (Wired)，点进去是灯光卡（关闭 / 静态颜色 / 波浪），和 r3 时代一致。

这次修好的是什么、还差什么

修好了：耳机重新出现在设备列表；有线灯光卡可用（关闭 / 静态 / 波浪，走 64 字节 Report 0x02）。

仍然没有（和 r3 一样，不是这次回归造成的）：

• THX 安装入口。它在音频页里，而音频页需要 91 字节接口才能发现这台耳机，所以拿不到。THX 本身是雷云的软件组件（THX 服务 + APO），装上才有空间音频 —— 我们打算把它挪到 Kraken 这一页来，让你能直接下载安装包，这需要单独做。
• 2.4 GHz 接收器 056C 的灯光仍未开放（上游没验证过无线灯光路径，不能把有线报文直接套过去）。
• 电量、EQ、麦克风仍需 91 字节接口，本机没有。

请完全退出正在运行的 OpenSynapse（包括托盘），删掉旧解压目录，再解压本包运行。此包为自包含测试包，未在 Kraken V4 实机验证。

SHA-256：D8444D80C7BB6D1F93BC74D0D860DD6952D64E84A729DB2DE142A26E4FAA94A0

English

Fixes the Razer Kraken V4 not showing up at all in v1.6.0.

This is a regression from our previous release, not a problem with your headset or the driver. You reported on 10-26 that the wired build showed it correctly, and it disappeared after v1.6.0 — the timing lines up.

What happened

On 10-26 we moved the Kraken lighting card from the lighting page to the audio page, so a headset would not appear twice. The condition was "if the model is on the audio page list, move it there".

But the audio page discovers a headset through the 91-byte feature interface, and the Kraken V4 exposes only a 64-byte FF14:0001 collection (your earlier log shows out=64 in=64 with no feature=91). So:

• The audio page never selected the Kraken V4, so it had no row there
• The lighting page stopped emitting its own row because "it is on the audio page list"

Neither page showed it, so the headset vanished.

The fix

The lighting card only moves to the audio page when the device really exposes the 91-byte feature interface. The Kraken V4 does not, so its lighting card stays on its own row again.

After this build, with the USB-C cable connected, the device page shows Razer Kraken V4 (Wired) with a lighting card (off / static colour / wave), the same as in r3.

What works now and what does not

Fixed: the headset appears in the device list again, and the wired lighting card works (off / static / wave over the 64-byte report 0x02).

Still missing (same as in r3, not caused by this regression):

• The THX installer entry. It lives on the audio page, and the audio page needs the 91-byte interface to find this headset, so it never shows. THX itself is Razer software (a THX service plus an APO) and needs to be installed for spatial audio. We plan to move it onto the Kraken page so you can download it directly; that is separate work.
• Lighting for the 2.4 GHz receiver 056C is still not exposed (the wireless path is unverified upstream, so the wired reports cannot be reused as-is).
• Battery, EQ and microphone still need the 91-byte interface, which this headset does not have.

Fully quit OpenSynapse (including the tray), delete the old extracted folder, then unpack this build and run it. This is a self-contained pre-release test build and has not been verified on Kraken V4 hardware.

SHA-256: D8444D80C7BB6D1F93BC74D0D860DD6952D64E84A729DB2DE142A26E4FAA94A0

HyperBoost power levels test build (2026-10-27)

Test build for the HyperBoost power report. / HyperBoost 功耗问题的测试包。

中文

HyperBoost 过去只把 EC 模式写成 7，CPU/GPU 功耗档位还停在自定义模式留下的值，所以功耗低于自定义。这版切 HyperBoost 时会同时把该机型已审核的最高 CPU 档位和 GPU High 档写进去，写完读回校验；切离 HyperBoost 时把自定义原来的档位写回去。写入失败会回滚模式，不会出现「显示 HyperBoost、实际低功耗」。

机型没有 CPU 档位的（02B7）保持原行为。

English

HyperBoost used to write only the EC preset byte, leaving the CPU/GPU power levels at whatever Custom had stored. This build also writes the model's highest admitted CPU level and GPU High with the preset, verifies both on readback, and restores the Custom levels when the preset is left. A failed level write rolls the mode back instead of leaving the machine on a lower budget.

Models without CPU levels (02B7) keep the previous path.

验证 / Verification

• 1005 unit tests pass, including a new 02C6 fake-transport test for the write and restore path.
• Not verified on real 02C6 hardware; the level write in HyperBoost mode is what needs measuring.

OpenSynapse DeathAdder V3 Pro polling r1 (2026-10-27)

中文

修复 Razer 炼狱蝰蛇 V3 Pro（DeathAdder V3 Pro）在接收器与有线两种模式下都无法调整轮询率的问题。

根因不在协议，在我们的设备目录。 这台鼠标有四个 USB 身份，之前的 pollRates 全是 null：

PID	官方机型	之前的档位	现在的档位
00B6	DeathAdder V3 Pro（有线本体）	无（控件不显示）	125 / 500 / 1000 Hz
00B7	DeathAdder V3 Pro（无线接收器）	无（控件不显示）	125 / 500 / 1000 Hz
00C2	DeathAdder V3 Pro HyperPolling（有线本体）	无（控件不显示）	125 / 500 / 1000 Hz
00C3	DeathAdder V3 Pro HyperPolling（无线接收器）	无（控件不显示）	125 / 500 / 1000 / 2000 / 4000 / 8000 Hz

档位列表为空时，轮询率下拉框和「保存」按钮整块不渲染，所以无论插在接收器上还是插线，页面上都找不到可操作的控件 —— 不是点了没反应，是控件根本没出来。

8K 档位只在 00C3 接收器上打开，因为官方 JS 的 8K 判定（isHyperpollingWireless）只在接收器路径生效，而 00C3 走的是高速轮询报文 00:C0（读）/ 00:40（写），与已经实测可用的 Viper V3 Pro 接收器（00C1）同一套。有线本体 00C2 官方档位列表就是三档，所以只给三档。

同时：00C2 / 00C3 在设备列表里原本与 00B6 / 00B7 显示成同名，现在改名加 HyperPolling 标识，方便区分两台不同的机器。

请完全退出正在运行的 OpenSynapse（包括托盘），下载本包解压运行，然后复测：轮询率卡片应出现档位下拉框与「保存」按钮；插在接收器上还应能看到 8000 Hz 一档。此包为自包含测试包，未在 DeathAdder V3 Pro 实机验证。

SHA-256：E7BE1318C43E9178AB125923AC3452F5397E4CB426D954219E84EAD7F723A296

English

Fixes the Razer DeathAdder V3 Pro being unable to change its polling rate in either the receiver or the wired mode.

The cause is our device catalog, not the protocol. The mouse has four USB identities and all of them shipped with an empty rate list, so the polling dropdown and the save button never rendered at all — there was no control to click, in either mode.

PID	Official model	Rates before	Rates now
00B6	DeathAdder V3 Pro (wired body)	none (no controls)	125 / 500 / 1000 Hz
00B7	DeathAdder V3 Pro (receiver)	none (no controls)	125 / 500 / 1000 Hz
00C2	DeathAdder V3 Pro HyperPolling (wired body)	none (no controls)	125 / 500 / 1000 Hz
00C3	DeathAdder V3 Pro HyperPolling (receiver)	none (no controls)	125 / 500 / 1000 / 2000 / 4000 / 8000 Hz

The 8 kHz rates are opened on the 00C3 receiver only: the official 8 kHz gate (isHyperpollingWireless) applies on the receiver path, and 00C3 answers the high-speed polling commands 00:C0 (read) and 00:40 (write), the same pair the already verified Viper V3 Pro receiver (00C1) uses. The wired body 00C2 lists three rates in the official bundle, so it only gets three.

The 00C2 and 00C3 entries also used to share a name with 00B6 and 00B7 in the device list; they now carry the HyperPolling label so the two mice are distinguishable.

Quit the running OpenSynapse (including the tray), unpack this build and retest: the polling card should now show a rate dropdown and a save button, and the receiver should also offer 8000 Hz. This is a self-contained pre-release test build; it has not been verified on a DeathAdder V3 Pro.

Capability table test build (2026-10-27)

Test build for the Leviathan V2 X read fix and the Blade 15 Base (Early 2020) capability table. / 音响读取修复与 0255 能力表的测试包。

中文

1. Leviathan V2 X：之前的校验和修复只落在传输层，解析层仍按原算法复核，所以「固件读取」「亮度读取」一直显示未读取。这版让解析层同时接受两种校验和，这两行应该变成已读取。
2. Blade 15 Base (Early 2020) / 0255：能力表里有 5 条这台机器不答的报文（0D:88 风扇 RPM、0D:8E 原生显示、0D:8F SKU、07:8C adapter、07:8F 电源掩码），已从 manifest 和族契约里删掉，诊断页不再出现这些红行，「部分可用」的分母也改成 4。

性能模式、亮度、充电上限不受影响。

English

1. Leviathan V2 X: the checksum fix only covered the transport. The parse helpers still compared against the shared range, so firmware and brightness reads kept reporting "not read". Both parse gates now accept either checksum form.
2. Blade 15 Base (Early 2020) / 0255: five reports this firmware does not answer (0D:88 fan RPM, 0D:8E native display, 0D:8F SKU, 07:8C adapter, 07:8F power-mode mask) are no longer declared, and the capability count now reflects the four reports the unit actually has.

验证 / Verification

• 1011 unit tests pass, including new coverage for the folded checksum parse path and the trimmed 0255 manifest.
• Not verified on hardware: the soundbar reads and the 0255 diagnostic page need a real run.

OpenSynapse Blade 16 (2023) fan/charge/MUX r1 (2026-10-27)

OpenSynapse Blade 16 (2023) RZ09-0483 测试包 r1（2026-10-27）

针对灵刃16 2023 的三项反馈，全部按雷蛇官方中间件 bundle 的实际行为修复。

1. 风扇转速现在可以自定义

官方 bundle 的 deviceUI 配置里有 performance.hasFanSpeed，四个性能档（平衡/静音/自定义/HyperBoost）各自带风扇区间，并且每个档都可以切"手动转速"。此前 OpenSynapse 的机型能力表没有给 029F 开固定风扇这一项，写入时被直接拒绝，界面上也就没有转速滑块。

• 滑块范围 3400–5000 RPM，步进 100 RPM
• 官方档位区间是 3400–5200（自定义档到 5300），但共享风扇报文的上限是 5000，所以滑块停在 5000；固件里已存的更高转速仍能正常读回
• 029F 不像 Blade 14 (2022) 那样只在自定义模式下生效，各性能档都可以设固定转速

2. 充电上限 0x4B 不再报"未知代码"

官方中间件读这一路报文的方式是：低 7 位是阈值，最高位是启用标志。此前 OpenSynapse 用的是写死的码表，固件合法返回的字节（例如 0x4B：未启用、阈值 75）会被当成未知代码抛错。现在改成官方的掩码语义：

• 已有的每个码值显示结果不变（50/55/60/65/70/75/80/100）
• 0x4B 这类"未启用"的字节不再报错，等效上限显示 100%
• 写入逻辑未改

3. 显示模式（MUX）可用

官方 bundle 用的就是 710 家族那套字节（读 0x0D:0x89 / 写 0x0D:0x09 / 能力位 0x0D:0x8A），029F 的 runtimeData 也明确 hasGPUmode。此前 blade-671 的 manifest 缺这三条能力，界面固定显示"设备未报告可切换的动态显示（DDS / Optimus）或独显直连能力"。

• 读、写、能力位三条都开放
• 只给 029F 开放：Blade 14 (2022) 和 Blade 15 同属一个协议家族，但它们的官方 bundle 从未应答过 VGA 报文

4. HyperBoost 提示

截图里"HyperBoost requires the Razer Laptop Cooling Pad..."这条来自配置自动应用路径，且只有当配置里存了 HyperBoost 才会出现。设备页手动选 HyperBoost 时会先弹免责确认，接受后会被记住（AppBehaviorSettings.PadlessHyperBoostAccepted），之后配置应用不再报这句。适配器功率门控保持不变。

本包的构建基线

构建自 commit 4ce21be（ProductVersion 1.6.0+4ce21be44a4c79369127a15c9d68868be7fc35e5），相对正式版 v1.6.0 还包含 Viper V3 Pro SE 旧版轮询协议、HID 响应路由修正、蓝牙设备页独立控件、Naga 侧键触发宏、无散热垫 HyperBoost、BlackShark V2 Pro 2023 的 MXIC 64 字节音频通道。

本包不含：高完整性宏提权 agent、九个中间件控件（Time To Dim / Indicator LED / GPU Card / Profile Debounce / Chroma Tap / Force Chroma / LK Scroll 等）、保存按钮焦点修复。这些在基线之后才合入 main，不在此包内。

验证

• 974 个单元测试全部通过
• Release 自包含构建 0 警告 0 错误
• 新增 tests/OpenSynapse.Core.Tests/Blade029FTests.cs 覆盖 MUX manifest 归属、充电上限解码、双上限拆分

请实测

1. 设备页风扇卡片是否出现"目标转速 (RPM)"输入框；设一个值（如 4000）后双转速计是否变化，切回"自动"是否恢复
2. 充电上限是否正常显示百分比，能否改
3. 显示模式（MUX）卡片是否出现，下拉框是否有可选项
4. 贴一份设备页诊断信息回来

SHA-256：73E541FE3D4BBF9C878C93743544DE2800564C350410647B1F86006BFFB95195