Rebound key events sent twice after suspend/resume #271
Description
Describe the bug
After waking from suspend, rebound mouse button events (e.g., back/forward buttons) are sent twice per press. This results in duplicate input events being registered by the desktop environment.
Device / program info
- Config:
{
"debug": false,
"listenPort": 27003,
"listenAddress": "127.0.0.1",
"cpuSensorChip": "",
"manual": false,
"frontend": true,
"metrics": false,
"memory": false,
"memorySmBus": "i2c-0",
"memoryType": 5,
"exclude": [],
"decodeMemorySku": true,
"memorySku": "",
"resumeDelay": 15000,
"logFile": "",
"logLevel": "info",
"enhancementKits": "",
"temperatureOffset": 0,
"amdGpuIndex": 0,
"amdsmiPath": "",
"checkDevicePermission": true,
"graphProfiles": true,
"cpuTempFile": "",
"ramTempViaHwmon": false,
"nvidiaGpuIndex": [
0
],
"defaultNvidiaGPU": 0,
"openRGBPort": 6743,
"enableOpenRGBTargetServer": false
}- lsusb output:
Bus 001 Device 002: ID 1b1c:1bdc Corsair CORSAIR SLIPSTREAM WIRELESS USB Receiver
- stdout.log: Not attaching full log, but errors show repeated "Unable to read data from device" messages.
Expected behavior
Single input event per button press for rebound keys.
Desktop (please complete the following information):
- OS: CachyOS Linux (Arch-based), kernel 6.17.9-2-cachyos
- Device Firmware: SLIPSTREAM 5.4.17, SCIMITAR RGB ELITE n/a
- Program Version: 0.7.2
Additional context
- Desktop: KDE Plasma 6 (Wayland)
- Device: Corsair SCIMITAR RGB ELITE mouse via SLIPSTREAM wireless receiver
- Both the physical Corsair mouse (event8, mouse1) and the OpenLinkHub virtual mouse (event29, mouse2) are registered as input devices
- The issue may be related to the evdev grab not being re-established correctly after resume
- Uncertain how to reproduce reliably - appears to be triggered by suspend/resume cycles but does not occur every time
Workaround
Restarting the service resolves the issue:
sudo systemctl restart OpenLinkHub.service