I just updated MacOS to Big Sur and CKB is bringing me to that "No devices connected" screen. I noticed at the end of your post you stated "Next release might also have one last macOS build", will this be a compatible update for Big Sur, or is there any troubleshooting I can do to make CKB find my keyboard now?

I wanted to thank you for all the hard work you have done for this program, as I can't imagine not being able to use my keyboard on my Mac without your program

I have no idea, honestly. I will not be testing against Big Sur, however I assume you need to allow Kernel Extensions (kexts) to load, since they were deprecated and I don't think they're loadable in the new version by default. You might have to disable system integrity protection to load it as well.
You can try force loading it with sudo kextload /path/to/vhid/kext to see what it complains about.

Additionally, you need to make sure (if it's still an option) that ckb-next-daemon can access your keyboard/mouse. It used to be an option under security and privacy.

As a sidenote, I just had a look, and apparently to use DriverKit you need "entitlement", and for that to happen you need to specify the USB device IDs.
In the past, Apple refused to sign kernel drivers to open source projects because they didn't own/manufacture the hardware.
I suspect it might be a similar case here, and if so, ckb-next is basically dead on macOS because we don't produce Corsair devices.

Some references:
https://developer.apple.com/support/kernel-extensions
https://developer.apple.com/documentation/driverkit/requesting_entitlements_for_driverkit_development

I tried your kexts script and it said it failed because the file could not be found. Also ckb-next-daemon is still an option and remains enabled in security.

It should be sudo kextload "/Library/Extensions/org.pqrs.driver.Karabiner.VirtualHIDDevice.v060800.kext"

This is what I got.

Executing: /usr/bin/kmutil load -p /Library/Extensions/org.pqrs.driver.Karabiner.VirtualHIDDevice.v060800.kext
Extension with identifiers org.pqrs.driver.Karabiner.VirtualHIDDevice.v060800 not approved to load. Please approve using System Preferences.

Firstly I would just like to say thank you for the MacOS support over the years I have been using Corsair keyboards.

 Secondly, I had the issue above with Big Sur, this was fixed with the Corsair iCUE for Mac software.

I definitely go with the flow regards how thankfully we all are for ckb. <3

 Secondly, I had the issue above with Big Sur, this was fixed with the Corsair iCUE for Mac software.

But for me iCUE is definitely not a suitable replacement by far. It’s not possible to address special keys like power button or fn, not to mention that permanent modifier remappings are not supported, too. On top of all is has a totally ugly status bar icon, which presence is not configurable =(

But for me iCUE is definitely not a suitable replacement by far. It’s not possible to address special keys like power button or fn, not to mention that permanent modifier remappings are not supported, too. On top of all is has a totally ugly status bar icon, which presence is not configurable =(

Yeah there are a load of features it is missing. I think it is still in beta so hopefully they will address it at some point.

Is it still beta? Looks pretty „released“ for me – at leats how it’s been advertised.

But good news from the hacky front:
I managed to get it running on Big Sur;
unfortunately not without disabling the System Integrity Protection;
and it needs to stay disabled otherwise the kernel extension will get discarded as it’s signature is seen as invalid – do I get it right?

Damn. I've been using CKB for years, and wish there was a Windows version so I'd never have to download CUE again 😅

On another note, are there any breaking changes in the works, or should just building CKB work for those of us holding out on Mojave/Catalina?

Okay, update:
I re-enabled the System Integrity Protection and the kext stays trusted and is loaded, also after reboot. 🙂

After a first unsuccessful try re-enabling SIP and having ckb still working, the second try worked for me. I think it was the additional boot after disabling SIP before re-enabling it again.

@blanorama that's good to hear. The kext is signed and has a valid signature, but I suspect it refused to load because of deprecated APIs.

@theLMGN Nothing planned on purpose, but if something breaks someone will need to fix it. I will 100% accept macOS fixes, but I will most likely not be testing on it or fixing them myself.

The project will remain as portable as possible, with Linux only code marked as such, as I am still planning on finishing the ckb-next windows port.

Thanks for all your support throughout this time!. This project has been extremely useful to make the corsair keyboards work with mac.

:/ I just updated to big sure :S and now ckb-next won't recognise my device... If I had known this - I would have not upgrade

@asad-awadia you should be able to disable SIP and run this command #660 (comment) to fix it

In my case I disabled SIP and running the command:

sudo kextload "/Library/Extensions/org.pqrs.driver.Karabiner.VirtualHIDDevice.v060800.kext"

and I have this on return:

Executing: /usr/bin/kmutil load -p /Library/Extensions/org.pqrs.driver.Karabiner.VirtualHIDDevice.v060800.kext

But nothing more happens, I presume it should prompt the message to allow the drivers in the privacy & security but it's not displaying anything. I'm also in Big Sur.

Edit: Just to say that I restarted the process and re-enabled again and then disabled and run the command and now it shows the prompt message to allow the drivers in security but there's no input monitoring permission for the library showing up so no keyboard is detected by ckb-next...

You need to add the ckb-next-daemon manually:
In Input Monitoring you press the plus sign and in the upcoming finder go to /Library/Application Support. In this folder, the ckb-next-daemon executable is located.

After that you need to restart the ckb-next-daemon. You do this by killing it with root rights (at least the way as I always do 🙈 😅 ).

@blanorama You're a wizard! Thank you so much! Just adding the daemon manually, redo the process of enabling the kext and restarting and it's again fully functional!

You’re welcome! 🙂
Just don’t forget to re-enable the SIP. I wouldn’t let it turned off.

@blanorama I was trying several times but always I re-enabled SIP, when I boot up and log in, it immediately prompts with a message blocking the extension 🤦‍♂️ ... Did you manage to make it work at the second try? Because it's the third try or so and still the same behaviour... I think I'll leave it unblock.

Yeah, I had the very same behaviour in the first try.
The second try I did an extra boot loop before re-enabling SIP. Thus I got it working but did not re-enable it directly afterwards it but still booted normally again. After this extra boot loop I shut down and then went on to recovery mode.
I think that exactly made it. Curios why this is not doing the trick for you 🤔

PS: ah, and I needed to delete the trusted kext policy from the kext policies sqlite DB in recovery mode to get started for the second try as in the second try it did not ask me to trust the extension (as the team of ‚Fumihiko Takayama‘ was already trusted);
(I did this according to informations found here: /private/var/db/SystemPolicyConfiguration/KextPolicy)
But be careful ⚠️ these steps and operating with this DB is yellow zone.

@blanorama It's curious because it's exactly the same steps I reproduced on my machine, not even needed to remove policy entries in sqlite in order to do a fresh installation 🤔

I think I will leave it as it is, it's not a big problem for me to be "vulnerable"... for a person who was dealing with macs and hackintosh, sometimes I found myself dealing with this stupid SIP security that brought me more problems rather than solutions.

Thank you again for your time 😉

again you’re welcome! take really care leaving it disabled
… and maybe you wanna do another try re-enabling it after time

(… tbh: Actually, I was really wondering why it worked when enabling SIP ➡️ I’m not the person believing in horoscope, voodoo or extra boot loops 😅
but there must be macos specialities working deeper – obviously 🙄 )

maybe outdated – maybe interesting – and maybe @Tonetete doesn’t want to run around with disabled SPI forever:
I had to reinstall macOS and found myself dealing with SPI kicking out the kext as soon I enable it – the same as @Tonetete above. ⬆️
I knew I got it running somehow in my last installation – with SPI enabled. So I dug a little bit more in the links I found previously regards this topic. Especially this karabiner elements issue pqrs-org/Karabiner-Elements#2190 gave me a hint.
I remember that I manually added the kext’s developer’s team ID (Fumihiko Takayama) to the kext consent list with this command run in recovery mode:
spctl kext-consent add G43BCU2T37

That was the missing trick I did not mention to you @Tonetete in the previous posts – sorry for that 😬. After that, in a subsequent recovery session (not the same) I could re-enabled SPI and the kext remains now stable. Thus completely nice and secure ckb-next. At least for Big Sur now…

@blanorama you're a wizard! I see that post a couple of days ago, pending to try it and it's working flawlessly again! Thank you so much!

man i hate iCUE not as smooth and simple that CKB-Next has. Is there going to be an auto mode switch for when entering a different program etc VS Code IDE to Chrome? or is there already something like this in the macOS Catalina Version?

The idea of snooping on people's running processes makes me a bit uncomfortable, honestly, which is what you have to do to implement that kind of thing.

fwiw this still isnt working for me

In order to restore support for macos, I thought about learning QT by myself, in the end too busy with work, so didn't take care of it ....

Qt is the least of your problems when trying to restore support for macOS. The problem is that ckb-next needs a way to:

• send USB data to devices
• send input data to the kernel

And in recent macOS that requires the driver to be a SystemExtension, and to be loaded it has to be signed by Apple. But Apple won't sign a certificate for us because we aren't Corsair, so we fundamentally can't talk to anything.

Ugh, it seems hard, but now I know a little bit more about how 'ckb-next' works. thanks ！

Qt is the least of your problems when trying to restore support for macOS. The problem is that ckb-next needs a way to:

• send USB data to devices
• send input data to the kernel

And in recent macOS that requires the driver to be a SystemExtension, and to be loaded it has to be signed by Apple. But Apple won't sign a certificate for us because we aren't Corsair, so we fundamentally can't talk to anything.

Not to beat the dead horse but have you been explicitly denied a certificate with Apple? I ask as I've been able to get System Extension entitlements for a Qualcomm USB VID:PID even though I have no affiliation with Qualcomm.