How does Input Remapper work?

[^faldo^]

I'd like to know more about this great little app. I'm running a Macbook, so I don't know how it responds on other, more powerful Macs.

 

As far as I'm aware, the Fn key on any laptop keyboard doesn't generate a scancode (command that corresponds to a function) to make the key transposition easy. Is there a scancode generated by Windows when you press the FN key on a macbook? If so, is there a shift-key-to-enable-capitilisation registry hack going on, using Windows' multimedia keyboard scancodes?

 

Or is it something more sinister, like hardware level key detection and that?

[Beliyaal]

I'd like to know more about this great little app. I'm running a Macbook, so I don't know how it responds on other, more powerful Macs.

 

As far as I'm aware, the Fn key on any laptop keyboard doesn't generate a scancode (command that corresponds to a function) to make the key transposition easy. Is there a scancode generated by Windows when you press the FN key on a macbook? If so, is there a shift-key-to-enable-capitilisation registry hack going on, using Windows' multimedia keyboard scancodes?

 

Or is it something more sinister, like hardware level key detection and that?

 

Before version 0.9.15 remapping was implemented with low level keyboard hooks. This worked well most of the time, but didn't work so well other times, and it also interfered with other programs that use low level hooks. I managed to get it pretty stable by rehooking all the time to make sure I was the first hook called. This was a tricky because I needed two hooks at the same time to make sure I didn't miss any input events. It also had problems with IME input (japanese), alt-tabbing and I had to create one thread for every desktop to capture events on the login desktop etc. I solved all of them except for the IME input.

 

So I decided I would create a driver because:

* It would be cleaner

* I wouldn't interfere with any other programs

* I should be able to solve the stuttering under heavy load that I experienced with hooks.

* I can now know what device every event comes from so I can remap differently for different keyboards/mice (This isn't implemented yet).

* It would solve the IME and probably "shortcuts isn't working problems" I have had reported

 

So now the driver:

Actually there are two drivers. One of them has been installed from the first version I released to make windows recognize the fn key as the "menu key". This driver is implemented as a upper filter to the MacBook keyboard. Basically it looks at USB packets before it goes to the USB hid parser and patches the data.

 

To the filter driver. This driver is implemented as a lower filter to the keyboard and mouse classes. This means that it will be loaded into the driver stack of every mouse and keyboard in the system. It will intercept PS2 scancodes / mouse input before they get to mouclass and kbdclass by replacing the callbacks that usually goes to the class drivers.

 

When input is received from devices it's put serialized into a global input queue in the filter driver. The Input Remapper service then reads this queue by a file device opened to the driver. The Input Remapper service then do all the remapping logic and generate new input packets and write to the driver file device. The filter driver then calls the original callback into the class drivers and thus windows sees the input.

 

Installation of the driver is accomplished by creating the service (InputRemapperFilter) that is the driver and then adding the filters by modifying registry keys. The mouse class filter would be:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96F-E325-11CE-BFC1-08002BE10318} REG_MULTI_SZ UpperFilters = InputRemapperFilter mouclass