No kernel file specified

[Tog1s]

And after this command

sudo kextutil \
    /System/Library/Extensions/IOUSBHIDDriverDescriptorOverride.kext

I get this error

No kernel file specified, using '/mach_kernel' 

I have OSX 10.8.3 and xcode 4.6.2. Any ideas?!

[thefloweringash]

That looks like a warning. Was the kext successfully loaded?

[Tog1s]

Yes it was. But keyboard still doesn't work. I have 1007-8400.

[Tog1s]

I was trying to install kext once again and realized that if I was typing Q W E R T Y before installing the driver I got

 km/ jlm.` l`ikm,/ ijkm,./ klm/`

But after installing the driver I got

 km jlm l ikm ijkm klm

Looks like kext is working but it's working incorrectly.

[thefloweringash]

This seems to be something entirely new. The "regular" behaviour without the kext is a mostly functional keyboard, where, for example, pressing the a key results in an a as well as another key.

How does typing Q W E R T Y result in the output? Does q input km, and w results in jlm and so forth?

Can I get the report descriptor? Ideally from rake scan, but a bus probe from the Apple utility would also work.

[thefloweringash]

Testing a hypothesis: Does pressing l result in ijkl, and does pressing m result in m?

[Tog1s]

Yes hypothesis is right. My descriptor after rake scan https://gist.github.com/Tog1s/5488414

[thefloweringash]

Looking at the descriptor you keyboard doesn't look much different from the one in #4, except for swapped space and enter buttons. However your keyboard appears to be sending full bytes instead of the expected bitset. The l key is usage 0xf, which is 0b1111, and apparently corresponds to the position of i, j, k, l in the bitset. I wouldn't be surprised if pressing more than one key at once resulted in letters other than i through m.

Since the actual report doesn't seem to match the descriptor at all, I'm curious about how it behaves on other platforms. Does it work on Windows? If so, does it have NKRO?

The kext can certainly override the descriptor with one that matches the behaviour of your keyboard, but since it's completely unlike the other Noppoo keyboards I've seen it will take a bit more work to make an appropriate descriptor. This doesn't explain what's causing the behaviour, and could very well be just fixing the symptoms. As a first step, I've prepared a build that uses a standard keyboard descriptor.

[Tog1s]

It is working on windows properly. This build is working properly on Mac OS X 10.8.3. All keys are working right as I thought. Thank you for your help. I appreciate it.

[douglasg]

Hi, just read this issue with the km jlm l ikm.... and thats exactly what i also get when i boot directly into osx, https://github.com/thefloweringash/iousbhiddriver-descriptor-override/issues/7

For me its working only when i first boot to windows and then reboot straight to osx, does windows send some usb commands to the keyboard and of this it change its behaviour?

[Tog1s]

I don't think so, it started working after

As a first step, I've prepared a build that uses a standard keyboard descriptor.

[thefloweringash]

@douglasg Sorry I didn't realise what you were seeing sooner. I hadn't seen this behaviour, and the documentation isn't clear about what problems are fixed. Support for these new keyboards is still in progress.

USB keyboards have a boot protocol, which is a simple standard keyboard for use without a full HID driver, for things like boot loaders and lower level applications. The operating system sends a "set protocol" request to change to the high level mode that uses the descriptor from the device. I'm guessing the Noppoo keyboards aren't leaving boot mode in OS X, but are on Windows. This would explain why booting to Windows makes the keyboard work. The build above forces the standard boot descriptor, so is probably patching this symptom without fixing the problem.

Can I please get a Bus Probe (from USB Prober.app in the February 2012 version of Hardware IO Tools for Xcode)? I'm aware I've asked for the results of rake scan, as they're easier to work with, but for this problem they don't contain enough information.

I have a guess what might be wrong, which I will hopefully confirm with the bus probe, and hope to have some time in the next couple of days to prepare a test build.

[douglasg]

Bus Probe from my working iMac after windows boot: https://gist.github.com/douglasg/5527205

Bus Probe from not working iMac (different one where i cant boot to windows ) https://gist.github.com/douglasg/5527218

@thefloweringash Thank you very much for looking into this. i love this keyboard and would like to use it also on my office iMac.

[thefloweringash]

My guess was quite far off. We're going to need more experimenting. Fortunately there's a hint in #12: Enabling caps-lock puts the keyboard into its proper high level mode. It's possible the protocol switch is caused by the request to set the led state: SET_REPORT.

Experiments! Use the latest version of the driver (not issue-10-1.pkg) and check keyboard is in boot mode before starting each test, i.e. l results in ijkl.

Experiment 1 - Caps lock button Press caps lock. Since caps lock probably won't work on the Noppoo, you might have to use another keyboard. If caps lock on one keyboard doesn't affect others, install KeyRemap4MacBook or skip to the next test.

Experiment 2 - SET_REPORT with caps lock enabled. Run scripts/set-leds.rb. Hopefully all the leds on the Noppoo will light up.

Experiment 3 - SET_REPORT with no leds enabled. Run scripts/set-leds.rb 0.

Do any of these make the keyboard work as expected (ignoring swapped space and enter)?

[douglasg]

Results:

Keyboard is in boot mode, key 1 = jklm

1. Caps lock from other keyboard => led from noppoo gets on, key 1 = JKLM
2. set-led => all leds are on, key 1 = jklm
3. set-leds.rb 0 => all leds are off, key 1 = jklm

[thefloweringash]

Well, that's frustrating.

Thank you for running through those.