This is probably unsupported in any way by Jason so please don't report bugs in other threads when using this solution. If you have any problems with this setup it is better to post them here and I'll try to help if I have time to do so.   Hi,   This how-to is for users who want to build more advanced control schemes using their Flirc devices. It is mainly directed to Windows users because there is no way in Windows to capture input from a single keyboard, but can be done in Linux. But it should be also applicable in other OS-es when used with correct software.   The problem is that not everything can be done just by defining a single key combinations. There are applications like AutoHotKey (AHK) or EventGhost (EG) that can capture specific key combinations but there is a problem. Having many buttons on the mapped remote it is sometimes hard to find key combinations that are not used as OS or other apps shortcuts already. By capturing the specific key combination in AHK or EG user basically blocks this combination even on a normal keyboard connected to the PC (as there is no way in Windows to capture only input from one specific keyboard).   Here comes HID standard for the rescue. HID keyboards are just one of the many usages of this standard. Because of that the HID standard has been split into multiple usage tables. Standard keys on keyboards use table 7 and in Windows codes from this table are immediately captured by HID keyboard filter driver and are converted into key presses. On the other hand keys like multimedia keys are defined in usage table 12. Codes from this table are not captured by the Windows. Only a few of them are natively supported (like volume, mute, play, pause etc).   Flirc GUI and CLI util provide the ability to map only a few of the keys from table 12. Those keys when mapped are not recognized by AHK or EG when used with keyboard input plugins. This gave me an idea to do some experiments. I needed to find out how these multimedia keys are stored in the Flirc which can be checked by inspecting saved config file. After that I checked if I can assign any HID code from the table 12 and I was successful.   I've found out that there is a key code which acts as a marker for Flirc to send usage 12 instead o 7. When this marker is found then the actual HID key ID is stored as a modifier. It is possible to use flirc_util to map almost any code from table 12: flirc_util.exe record_api 176 102 where 176 is decimal value of key ID (Play key in this case) and 102 is a marker that tells Flirc that this is key from table 12.   Table 12 has more than 256 keys defined but unfortunately Flirc can only hold a single byte value so there is still a restriction in the number of keys.   There are also holes in the list of keys in this table which I've used in my own config so I don't have any conflicts with other hardware and software. These are the usable values: 4-31, 34-47, 55-63, 73-95, 103-127, 159, 165-175. There are probably more but I've stopped looking other codes that are not mentioned by the standard. I think that other keys that are in the standard are also usable. Most of them are not natively supported by the Windows but I used these ranges in my case to be on the safe side. The way to record these keys is to change the first value to one in these ranges and record a button to them incrementally.   In my setup I've used EventGhost to capture HID events and map them to things I want them to do. It provides some nice features like programmable on screen menus and many plugins for specific apps like XBMC (it uses XBMC RPC API). To capture events from HID device a Generic HID plugin must be used. Unfortunately there is a small problem with this plugin and it sometimes sends multiple HID events on single button press (this is not the same problem as with repeated keys). I have a modifier Generic HID plugin that works very well with Flirc in this mode of operation. I can share it if there is a demand for it. I can also extend the how-to to some basic EG configuration.   I haven't used AHK but I know that there is also a way to capture HID events in it and use them to control things.   All the numbers I'm referring to are taken from this document http://www.freebsddiary.org/APC/usb_hid_usages.php