18 Dec
There have been a lot of blog posts around the internet about how to fix or change the “zoom” feature on the Microsoft Natural Ergonomic Keyboard 4000 into a scroll up/down feature instead — my favorite is this one by Olivier Dagenais which suggested using an XSL transform.
However, nobody seems to have fixed the F-Lock problem … so I started digging into the command mapping to see what I could figure out. I’ve got a fix posted at the bottom, so if you don’t care how this works, just skip to the end. I’m working on a Natural Ergonomic 4000, but some of what I found should apply to any keyboard using Microsoft’s IntelliType software. What we all know by now is that it has xml-based command remapping. The definitions for the remapping are in a file called commands.xml in the install directory, which is, by default: “C:\Program Files\Microsoft IntelliType Pro”.
There’s two interesting things happening in the IntelliType software. First, the “My Favorites” buttons on the Natural 4000 don’t seem to be a part of this remapping scheme. Second, although all of the remapping can be done in the commands.xml file, the control panel (at least in Vista) doesn’t use the commands.xml file at all — it adds entries to the registry!
The mappings from the control panel happen in this key: HKEY_CURRENT_USER\Software\Microsoft\IntelliType Pro\EventMapping and I’ll list the subkeys off here really quick:
I’ll add some more information here later about the possible contents of these keys, but the most important thing is this: the Command value dictates what the button does There is also a “ShellExecute” value which has a file path or URL that can be launched if the Command is set to 800 (decimal). The possible values for Command are basically all the different built-in commands — which are listed in the mscmdkey.xml file.
The weird thing is that some of the commands in mscmdkey don’t make sense as commands (like RSSI_NOISE_COMMAND or BATTERY_CRITICAL_COMMAND). Additionally, some of them can’t actually be used (you can’t remap F1 to “313” which is the left window key). I’ll mostly let you read the commands for yourself from that file. A couple of them are worth giving more detail about:
The real power of the IntelliType system is the Commands.xml file. Unlike the registry settings, which are restricted to remapping the keys from one “command” to another, the Commands.xml file can actually create simple macros. Commands.xml consists of a root node DPGCmd which contains the copyright and version nodes, and a series of language nodes. The most important language node is the global “ALL” language. The “ALL” language contains mappings which are applied on top of whichever language you have your keys set to, and you should be aware of it whenever you’re doing remapping because if you map the same character twice in the same section (eg: for the same app) it will crash the IntelliType driver, even if the mappings are in your language section (eg: ENG for english) and the ALL section. If you only ever use a single language on your keyboard, the simplest thing to do is to just get rid of all the other nodes in the file to avoid these conflicts.
Each Language (including ALL) has a series of APPLICATION tags with per-application key maps. This is actually a very cool feature, except for the fact that they remapped keys like F5 and F3 which already have functions in most apps! At any rate, the key maps are defined as tag like:
Each of the function keys map to a special command when the F-Lock mode is on … (you know them, because they’re labeled appropriately). For instance, the “Help” command, which is the F1 key, is command 302, so it appears in the commands.xml as <C302 ... />. The other interesting key, to me, is the scroll wheel, which turns out to behave somewhat like a key with variable-speed repeat. I’ve listed them below with the key they map to when F-Lock is engaged:
Having said all of that … the simplest thing to do is to just delete the whole EventMapping key and remap the F1-F12 keys in the commands.xml using an XSL style sheet like the one Olivier suggested. So, heter’s my IntelliType Fix – Right-Click and “Save As” to download it, and then apply it to your Commands.xml file. If you don’t know how to use an Xsl file, you could use my XSLT (eXtensible Stylesheet Language Transformation) PowerShell script and make a backup copy of your commands.xml called commands.xml.old and run this, in PowerShell:
2 Responses for "Hacking the Natural 4000 keyboard"
Thanks for taking the time to put this together! I found it extremely helpful. Karma++!
Thanks for this information since I’m annoyed with the limitations in the IntelliType software. Between this information and some information on the Autohotkey site I was able to remap all my special keys on this keyboard to do whatever I want using the well-documented and feature-filled autohotkey software (rather than the limited intellitype software).
In case it’s of use to anyone else, here’s what I did.
You can create scripts directly using Autohotkey for any of the key codes that it can pick up. Use its instructions to discover the key codes for the special buttons and then set these keys to “disabled” in the intellitype software control panel so you can work with them directly with Autohotkey.
Unfortunately, the favorites 1-5 and the help, undo, etc (alternate F1-F12) keys don’t send any special keycodes that Autohotkey can recognize. To send these keys to Autohotkey you need to do what you describe here and remap the keys in the IntelliType configuration files and registry to send keystrokes which Autohotkey can then pick up. For example, I’m having the Help (F1) key send ALT-CTRL-SHIFT-F1 from the IntelliType software which Autohotkey can pick up and do something more useful with.
I ran into the issue of almost not having enough of the Microsoft command numbers to remap all the keys that Autohotkey couldn’t pick up. As you noted, some actions like “logoff” will still take their action no matter how you remap them with the commands.xml file. The command ids I used that seemed (mostly) to work globally without undesired side-effects were 100, 101, 102, 103, 200, 201, 202, 203, 204, 301, 302, 307, 308, 309, 310, 311, 315. I deleted most of the application-specific actions from the commands.xml file and just left the “StandardSupport” section and an empty language section for English.
Removing application-specific settings isn’t a problem since autohotkey can also map keys differently depending on the application or active window if you want the keys to act differently in different applications.
I ran into problems with the ids 100-103. They would fire from IntelliType when a window was active, but the keys didn’t seem to fire when I was hovering the mouse over an icon on my desktop, for example.
I fixed the problem of special circumstance IntelliType keys by editing the mscmdkey.xml file and changing appCommand=‘36’ for each of these items. This appCommand number originally went with the copy command, but IntelliType didn’t care that some other items in mscmdkey.xml also used this appCommand too. It successfully changed the behavior so the key acted globally rather than just in a specific circumstance or window.
I’m thinking that perhaps some of the keys that don’t remap well to other behaviors might be able to be remapped to do standard key combinations by changing their appCommand number to 36 or one of the appCommands that doesn’t take any specialized action. Maybe it would be possible to use the commands such as “logoff” to do other things if you change their appCommands in mscmdkey.xml. I suspect the appCommand number references an action elsewhere (perhaps in one of those dlls) and the more extreme actions could be neutered by changing their appCommands to something else.
I hope this is helpful to someone out there.
Send a comment