iousbhiddriver-descriptor-override
iousbhiddriver-descriptor-override copied to clipboard
it doesn't work on el capitan
it doesn't work on el capitan
My Noppoo is working with this kext, but the signing behaviour for El Capitan is stricter, kext-dev-mode=1
no longer works. I'm working on providing an updated and signed version.
Keep an eye on this.
@leogong @thefloweringash
you can fix this problem by disabling System Integrity Protection(SIP) , see this: http://www.macworld.com/article/2986118/security/how-to-modify-system-integrity-protection-in-el-capitan.html
I tried, it works!
@fouber disabling SIP will fix the issue (as it turns off the kext signing check) but it's probably a bad idea. SIP is a security feature meant to protect the most important parts of the operating system from compromise. Disabling it won't leave you completely vulnerable, but you shouldn't do it unless you know the dangers and know what you're doing.
@lyallcooper
yes, it's a very temporary solution, at least I can use gem and my noppoo keyboard these days.
I want to add that I brought the USB – PS/2 – USB connectors do a workaround that I saw mentioned in the net: http://deskthority.net/wiki/NKRO-over-USB_issues
But unfortunately it didn’t made any difference on El Capitan: the Noppoo Choc Mini is still giving wrong outputs. So, I guess it all depends on Andrew Childs’s driver now. If anybody is curious, I am also writing about this topic on Plover Google Groups (but there have not been many answers yet): https://groups.google.com/forum/#!topic/ploversteno/sxTK7TKaxtg
Looking forward for a signed version! Or I got to spend $300 on a new hhkb...
I applied for the ability to sign kernel extensions, which I didn't realise Apple guard so closely, and received a seemingly generic negative reply. I'm continuing to argue the case, but I can't predict what the outcome will be.
For now, you can disable signature checking to be able to use your hardware.
See Apple's documentation for details. For what it's worth, you can disable parts of SIP, as documented on the Apple Developer Forums Post.
Oh my goodness, thank you for finding this temporary work around, I do not install unsigned software often so I don't think this will be a huge concern for security for me, however, good luck on getting your extension signed.
FWIW, to anyone who's thinking of disabling SIP fix the kext signing issue, it's possible to only disable the kext signature checking and leave all the other protections enabled.
All you need to do is in recovery mode after disabling SIP with csrutil disable
, enable it again but without kext signing enable with csrutil enable --without kext
. The util will give you a warning about this feature possibly being unsupported in future versions, so be forewarned this might be a bad idea.
@thefloweringash have you applied for the ability to sign kernel extensions?
I did back in October. The negative reply I received seemed fairly generic. I followed up but got no further response.
KEXT signing is intended for signing commercially shipping kexts or projects broadly distributed in a large organization. The use you describe does not need a signed kext.
KEXT signature checking for sample code and development use can be turned off on OS X El Capitan as described in the System Integrity Protection Guide located at ...
any update on this? Is there a workaround without disabling SIP? Thanks.