I have the thumb button set to Ctrl + Up for Mission Control. It works after starting my Mac or power-cycling the mouse, but stops working later. I've encountered this after locking and waking my Mac. Movement and the other buttons are fine, and Synapse still shows the correct assignment. Ctrl + Up on my keyboard also works.
My setup is:
MacBook Pro → Dell WD22TB4 Thunderbolt Dock → UGREEN CM662 USB 3.0 Switch → Basilisk V3 Pro 35K USB receiver.
I'm running macOS 27.2 (26B5091g), Synapse launcher 0.8.10 and Razer App Engine 4.4.24.
I reproduced it with this sequence:
1. Start with Synapse open and the thumb binding working. If needed, power-cycle the mouse to restore it.
2. Completely quit Synapse. The binding still works.
3. Reopen Synapse and wait for it to connect to the mouse and show it as active. The binding stops working.
Power-cycling the mouse with Synapse still open restores the binding again.
This test didn't require another sleep/wake cycle or any changes to the connection chain or saved assignment.
Switching profiles didn't fix it. Fully quitting Synapse has restored the onboard binding in a separate test. I'd expect the binding to keep working when Synapse connects and after wake.
Details for devs/engineers below:
Accessibility and Input Monitoring permissions were enabled, and both Razer drivers reported enabled.
The mapping-engine log reports:IORegistryEntryGetPath failed: 0xe00002c2
fail to probe hid endpoint
fail to probe filter driver
A read-only check of all three RazerGenericHIDDriverKit services found that IORegistryEntryGetPath fails, while IORegistryEntryCopyPath succeeds on the same handles in the same IOService plane. Each returned path is 511 UTF-8 bytes (512 including the null terminator), which appears to hit the legacy API's effective length limit with this dock/switch setup.
Inspection of libmapping_engine.dylib shows that GetEndpoints skips each service when this lookup fails, before calling IOServiceOpen.
While broken, the mouse reported driver mode and still sent raw thumb-button HID reports, but no Ctrl + Up. With the engine quit, thumb presses produced standard Ctrl + Up events again. This suggests software handling takes over without a working translation endpoint; the exact mode transition remains unconfirmed.
Could you investigate using IORegistryEntryCopyPath with dynamically sized path storage, and preserving onboard bindings when endpoint initialization fails?
I haven't tested a direct receiver connection. I can provide logs and the read-only reproducer if helpful.