Ckb-next: Corsair Scimitar not recognized after Restart macOS

Created on 5 Feb 2018  路  5Comments  路  Source: ckb-next/ckb-next

I am using the Corsair Scimitar on macOS High Sierra 10.13.3 and am using the latest release of ckb-next.

When I restart the computer with the mouse plugged in as the computer is booting, the ckb-next software does not recognize the mouse as existing, and no amount of quitting, restarting the program, or unplugging the mouse will make the software recognize it again. I have to restart the computer again, with the mouse unplugged, wait for a full boot, get past the login screen, and wait for ckb-next to start up, before I can plug in the mouse.

This is reproducible every time for me, and has been across 2 different computers, since Mavericks.

bug can't fix device-scimitar macOS

Most helpful comment

@OvermindDL1 This is a mac issue, in mac code, completely different than yours.

Additionally, this is a known issue. I couldn't find an open ticket, so I'll leave this one as-is, however it is only reproducible during OS boot.
If ckb-daemon is started afterwards, it doesn't happen.

The hang happens during device init, before the input thread starts. The only way to obtain a log is by installing the plist that logs stdout to a file.

Maybe a quick workaround would be to delay ckb-daemon during init.

All 5 comments

Just came to say that sometimes on linux (ubuntu) the scimitar is not recognized after a reboot until it is unplugged and plugged back in (not additional reboot needed), but it is not reliably reproduceable. So I'm guessing some kind of underlying issue?

Come visit us in IRC; I can't promise we can fix anything, but we can try. We would suggest you upload a ckb-dev-detect report, though. The template is there for a reason.

@OvermindDL1 This is a mac issue, in mac code, completely different than yours.

Additionally, this is a known issue. I couldn't find an open ticket, so I'll leave this one as-is, however it is only reproducible during OS boot.
If ckb-daemon is started afterwards, it doesn't happen.

The hang happens during device init, before the input thread starts. The only way to obtain a log is by installing the plist that logs stdout to a file.

Maybe a quick workaround would be to delay ckb-daemon during init.

Could this be related to/a dupe of #37?

Closing due to inactivity

Was this page helpful?
0 / 5 - 0 ratings