Using Raw Input from C# to handle multiple keyboards

Windows XP supports multiple keyboards, but by default, the .Net Framework will treat them all as one. This article explains how to use the Windows API Raw Input methods to support multiple keyboards from a C# application.

Introduction

There was a time when you were lucky if a PC had so much as a mouse, but today, it is common to have a wide variety of Human Interface Devices (HIDs) ranging from game controllers to touch screens. In particular, users can connect more than one keyboard to their PCs. However, the usual keyboard programming methods in the .NET Framework offer no way to differentiate the input from different keyboards. Any application handling KeyPress events will receive the input from all connected keyboards as if they were a single device.

Windows XP and above now support a "raw input" API which allows programs to handle the input from any connected human interface devices directly. Intercepting this information and filtering it for keyboards enables an application to identify which device triggered the message. For example, this could allow two different windows to respond to input from different keyboards.

This article and the enclosed code demonstrate how to handle raw input in order to process keystrokes and identify which device they come from. The Rawinput.dll file in the attached zip contains the raw input API wrapper; copy this dll to your own project and follow the instructions in "Using the code" if you want to use it without running the sample application.

Background

I recently published an article on implementing a low-level keyboard hook in C#[^] using the SetWindowsHookEx and related methods from user32.dll. While looking for a solution to handle multiple keyboards, Steve Messer[^] came across my article and we discussed whether my code could be adapted to his needs. In fact, it turned out that it couldn't, and that the Raw Input API was the solution.

Unfortunately, there are very few keyboard-related Raw Input samples online, so when Steve had finished a working sample of his code, I offered to write this article so that future .NET developers faced with this problem wouldn't have to look far to find the solution. While I have made minor adjustments to the code, it is primarily Steve's work and I thank him for sharing it. Note: as of March 2007, you can also download Steve's WPF sample illustrating the use of WndProc in Windows Vista. However, this article only describes the Windows XP source code.

Please note that this will only work on Windows XP or later in a non-Terminal Server environment, and the attached sample projects are for Visual Studio 2005. The latest update was developed using Visual Studio 2012 on Windows 8 64 bit. I do not believe the update has any dependencies on anything higher that .Net 2.0 so you can simply add the files to any version of VS that you might have.

Support for different devices

The attached code is a generic solution that mostly mirrors the sample code given on MSDN. Different devices will work in different ways, and you may need to amend the code to suit the keyboards you are using. Unfortunately, we won't always be able to help with device-specific queries, as we won't have the same devices you have. Steve Messer has tested the code with different keyboards, however, and is confident that it will work with most devices provided they are correctly installed.

Using the code

Most of the code related to raw input handling is encapsulated in the RawKeyboard and RawInput classes which reside in the rawinput.dll. Using it is a matter of implementing three simple steps:

1. Add a reference to rawinput.dll to your project.

Then add the following using statement.

<span id="ArticleContent">using RawInput_dll;
</span>

2. Instantiate an RawInput object

The RawInput class's constructor takes one argument, which is the handle to the current window.

The handle is required. When you register for rawinput the input is sent to the given handle. If you don't provide a handle then rawinput doesn't have a window to send messages to. The rawinput class now inherits from Native Window and overrides WndProc for you.

3. Handle the KeyPressed event

When a key is pressed, the RawKeyboard class raises a custom KeyPressed event containing an InputEventArgs. This needs to be handled by a method of the type DeviceEventHandler, which can be set up as follows:

The method that handles the event can then perform whatever actions are required based on the contents of the KeyControlEventArgs argument. The sample application attached to this article simply uses the values to populate a dialog box.

4. Optional Settings to control message handling and capture messages only if your application is top-most

Now, the RawInput class works by intercepting messages to the registered window handle in order to process the WM_INPUT messages containing raw input data. The window listening for raw input will therefore need to override its own WndProc and pass all its messages to the instantiated RawKeyboard object.

The rest of this article describes how to handle "raw input" from a C# application, as illustrated by the RawInput and RawKeyboard class's in the sample application.

Implementing a Windows API Raw Input handler

MSDN identifies "raw input"[^] as being the raw data supplied by an interface device. In the case of a keyboard, this data is normally intercepted by Windows and translated into the information provided by Key events in the .NET Framework. For example, the Windows manager translates the device-specific data about keystrokes into virtual keys.

However, the normal Windows manager doesn't provide any information about which device received the keystroke; it just bundles events from all keyboards into one category and behaves as if there were just one keyboard.

This is where the Raw Input API is useful. It allows an application to receive data directly from the device, with minimal intervention from Windows. Part of the information it provides is the identity of the device that triggered the event.

The user32.dll in Windows XP, Vista, and Windows 8 contains the following methods for handling raw input:

RegisterRawInputDevices allows the application to register the input devices it wants to monitor.

GetRawInputData retrieves the data from the input device.

GetRawInputDeviceList retrieves the list of input devices attached to the system.

GetRawInputDeviceInfo retrieves information on a device.

The following sections give an overview of how these four methods are used to process raw data from keyboards.

Registering raw input devices

By default, no application receives raw input. The first step is therefore to register the input devices that will be providing the desired raw data, and associate them with the window that will be handling this data.

To do this, the RegisterRawInputDevices method is imported from user32.dll:

To determine which devices should be registered, the method accepts an array of RAWINPUTDEVICE structures. The other two arguments are the number of items in the array, and the number of bytes in a RAWINPUTDEVICE structure.

The RAWINPUTDEVICE structure is defined in Windows.h for C++ projects, here is has been redefined for use in C#.

Each RAWINPUTDEVICE structure added to the array contains information on a type of device which interests the application. For example, it is possible to register keyboards and telephony devices. The structure uses the following information:

Usage Page: The top level HID "usage page". For most HIDs, including the keyboard, this is 0x01.

Usage ID: A number indicating which precise type of device should be monitored. For the keyboard, this is 0x06. (A list of Usage Page and Usage ID values can be found in this MSDN article on HIDs[^])

Here, the code only defines the RIDEV_INPUTSINK flag, which means that the window will always receive the input messages, even if it is no longer has the focus. This will enable two windows to respond to events from different keyboards, even though at least one of them won't be active.

With the array ready to be used, the method can be called to register the window's interest in any devices which identify themselves as keyboards:

Once the type of device has been registered this way, the application can begin to process the data using the GetRawInputData method described in the next section.

Retrieving and processing raw input

When the type of device is registered, the application begins to receive raw input. Whenever a registered device is used, Windows generates a WM_INPUT message containing the unprocessed data from the device.

Each window whose handle is associated with a registered device as described in the previous section must therefore check the messages it receives and take appropriate action when a WM_INPUT one is detected. In the sample application, the Rawnput class takes care of checking for WM_INPUT messages, so all the native window does is override its base WndProc method to get access to the messages, and pass the handle that generated the input to the RawKeyboard object's ProcessRawInput for processing:

The WndProc method in RawInput filters the messages, calling ProcessRawInput whenever a WM_INPUT is received. Any other type of message will fall through to the call to the base WndProc, so the application will respond to other events normally.

ProcessRawInput then uses the GetRawInputData method to retrieve the contents of the message and translate it into meaningful information.

Retrieving the information from the message

In order to process the data in WM_INPUT messages, the GetRawInputData method is imported from user32.dll:

hRawInput
The handle to the RAWINPUT structure containing the data, as provided by the lParam in a WM_INPUT message.

command
A flag which sets whether to retrieve the input data or the header information from the RAWINPUT structure. Possible values are RID_INPUT (0x10000003) or RID_HEADER (0x10000005) respectively.

pData:
Depending on the desired result, this can be one of two things:

If pData is set to IntrPtr.Zero, the size of the buffer required to contain the data is returned in the pcbSize variable.

Otherwise, pData must be a pointer to allocated memory that can hold the RAWINPUT structure provided by the WM_INPUT message. When the method call returns, the contents of the allocated memory will be either the message's header information or input data, depending on the value of uiCommand.

size
A variable that returns or specifies the size of the data pointed to by pData.

sizeHeader
The size of a RAWINPUTHEADER structure.

In order to ensure that enough memory is allocated to store the desired information, the GetRawInputData method should first be called with pData set to IntPtr.Zero.

Following this call, the value of dwSize will correspond to the number of bytes needed to store the raw input data (as indicated by the use of the RID_INPUT flag).

Now that the size of the inputdata , GetRawInputData can be called again to populate the _rawBuffer with the RAWINPUT structure from the current message. If it succeeds, the method returns the size of the data it retrieved, so it is worth checking that this matches the result of the previous call before continuing.

Processing the data

As mentioned above, the WM_INPUT message contains raw data encapsulated in a RAWINPUT structure. As with the RAWINPUTDEVICE structure described in the previous section, this structure is redefined in the RawInput dll as follows.

Following the second call to GetRawInputData (see previous section), the raw structure will contain the following information:

A RAWINPUTHEADER structure called header, which contains information on the message and the device that triggered it.

A second structure of type RAWKEYBOARD called keyboard. This could also be a RAWMOUSE or RAWHID structure called mouse or hid, depending on the type of device.

Its members return the following information:

dwType
The type of raw input the message represents. The values can be RIM_TYPEHID (2), RIM_TYPEKEYBOARD (1), or RIM_TYPEMOUSE (0).

dwSize
The size of all the information in the message (header and input data included).

hDevice
The handle of the device which triggered the message.

wParam
The wParam data from the WM_INPUT message.

The second structure will be a RAWMOUSE, a RAWKEYBOARD, or a RAWHID type. For the sake of completeness, the Rawinput dll does contain definitions for RAWMOUSE and RAWHID, though it is only designed to process keyboard information.

The keyboard information is provided by a RAWKEYBOARD structure, laid out as follows.

The next step is to filter the message to see if it is a key down event. This could just as easily be a check for a key up event; the point here is to filter the messages so that the same keystroke isn't processed for both key down and key up events.

At this point, the RawKeyboard class retrieves further information about the message and the device that triggered it, and raises its custom KeyPressed event. The following sections describe how to get information on the devices.

Retrieving the list of input devices

Although this step isn't required to handle raw input, the list of input devices can be useful. The sample application retrieves a list of devices, filters it for keyboards, and then returns the number of keyboards. This is part of the information returned by the InputEventArgs in the RawKeyboard class's KeyPressed event.

pRawInputDeviceList:Depending on the desired result, this can be one of two things:

IntPtr.Zero if the purpose is only to retrieve the number of devices.

A pointer to an array of RAWINPUTDEVICELIST structures if the purpose of the method call is to retrieve the complete list of devices.

uiNumDevices:A reference to an unsigned integer to store the number of devices.

If the pRawInputDeviceList argument is IntPtr.Zero, then this variable will return the number of devices.

If the pRawInputDeviceList argument is a pointer to an array, then this variable must contain the size of the array. This allows the method to allocate memory appropriately. If uiNumDevices is less than the size of the array in this case, the method will return the size of the array, but an "insufficient buffer" error will occur and the method will fail.

cbSize:The size of a RAWINPUTDEVICELIST structure.

In order to ensure that the first and second arguments are correctly configured when the list of devices is required, the method should be set up in three stages.

First, it should be called with pRawInputDeviceList set to IntPtr.Zero. This will ensure that the variable in the second argument (deviceCount here) is filled with the correct number of devices. The result of this call should be checked, as an error means that the code can proceed no further.

The pRawInputDeviceList data can then be converted into individual RAWINPUTDEVICELIST structures. In the example below, a for loop has been used to iterate through the devices, so i represents the position of the current device in the array.

Getting information on specific devices

Once GetRawInputDeviceList has been used to retrieve an array of RAWINPUTDEVICELIST structures as well as the number of items in the array, it is possible to use GetRawInputDeviceInfo to retrieve specific information on each device.

hDevice
The device handle returned in the corresponding RAWINPUTDEVICELIST structure.

uiCommand A flag to set what type of data will be returned in pData. Possible values are RIDI_PREPARSEDDATA (0x20000005 - returns previously parsed data), RIDI_DEVICENAME (0x20000007 - a string containing the device name), or RIDI_DEVICEINFO (0x2000000b - an RIDI_DEVICE_INFO structure)

pData:Depending on the desired result, this can be one of two things:

If pData is set to IntrPtr.Zero, the size of the buffer required to contain the data is returned in the pcbSize variable.

Otherwise, pData must be a pointer to allocated memory that can hold the type of data specified by uiCommand.
(Note: if uiCommand is set to RIDI_DEVICEINFO, then the cbSize member of the RIDI_DEVICE_INFO structure must be set to the size of the structure)

pcbSize
A variable that returns or specifies the size of the data pointed to by pData. If uiCommand is RIDI_DEVICENAME, pcbSize will indicate the number of characters in the string. Otherwise, it indicates the number of bytes in the data.

The example code uses a for loop to iterate through the available devices as indicated by the deviceCount variable. At the start of each loop, a RAWINPUTDEVICELIST structure called rid is filled with the information on the current device (see GetRawInputDeviceList section above).

In order to ensure that enough memory is allocated to store the desired information, the GetRawInputDeviceInfo method should first be called with pData set to IntPtr.Zero. The handle in the hDevice parameter is provided by the rid structure containing information on the current device in the loop.

In this example, the purpose is to find out the device name, which will be used to look up information on the device in the Registry.

Following this call, the value of pcbSize will correspond to the number of characters needed to store the device name. Once the code has checked that pcbSize is greater than 0, the appropriate amount of memory can be allocated.

Reading device information from the Registry

This string mirrors the device's entry in the Registry; parsing it therefore allows us to find the relevant Registry key, which contains further information on the device. So the first step is to break down the relevant part of the string:

All that is left then is to deallocate any allocated memory and do something with the data that has been retrieved.

What's new?

1. Pre message filtering. The allows the messages that aren't WM_INPUT messages to behave normally. ProcessRawInput returns true if it successfully decodes a keypress event else false. Returning true causing the message to not be sent to the WndProc method.

3. Determine if the ctrl and alt keypress are the left or right version. When the RI_KEY_E0 flag is set it said that the EO bit is set, which means the right version of a key was pressed. The shift key is a little different. It is a right shift if the makecode has the SC_SHIFT_R bit set.

Conclusion

Although the .NET Framework offers methods for most common purposes, the Raw Input API offers a more flexible approach to device data. The enclosed code and the explanations in this article will hopefully prove a useful starting point for anyone looking to handle multiple keyboards in an XP or Vista based application.

Sources

This article gives an overview of the different steps required to implement the Raw Input API. For further information on handling raw input:

Share

About the Authors

Emma's first steps in programming took place at primary school over thirty years ago, thanks to a TI-99/4A and the LOGO language. Following a Master's degree in English Studies (obtained, strangely enough, with a paper on the birth of the microcomputer), Emma started her career in IT.

Over the last ten years, she has worked as a localiser, technical writer, editor, web designer, systems administrator, team leader and support engineer, before finally making the move into software development a few years ago. She is now thrilled on a daily basis that she is getting paid for writing code after doing it for free half her life!

Comments and Discussions

Hi, I'm trying to use multiple numberpads and I'm trying to handle the keypresses done on Keypad No.2 then block the input so it won't reach any open windows. Anybody knows how to block the input? Thank you in advance

I am working on a project which I have to transfer every input from a barcode scanner into another code. For example, if the scanner input 680XXXX, my application transfer it into 800XXXX, and then send to the textbox(screen focus). And if the input is from other devices (ps2 keyboard or usbhid keyboard), does not filter it at all ( let it directly send to the textbox). How can I achieve this?

Trying to explore further in IMessageFilter, to filter specific devices, I found this:

In your code you implement a basic filter that intercepts WM_KEYDOWN messege. It is simple and works great, but you can't filter by device because WM_KEYDOWN does not provide this info.

But, after some reading, I'm quite sure that WM_INPUT - WM_KEYDOWN are sent in pairs, in this order, so first a WM_INPUT is sent, then a WM_KEYDOWN. Correct me if I'm wrong. Can I rely in this?

So my solution (it works till now) is create a filter IMessageFilter class that intercepts WM_INPUT messages and WM_KEYDOWN messages. When a WM_INPUT message comes, you read the device info (handle or name), and if its coincident with the one you want to filter (you can provide it in the class constructor), you raise a flag to discard next incoming WM_KEYDOWN message.

The two of you have completely dissected Raw Input on a programming level.
This week, I've been investigating this approach versus using SetWindowsHookEx and LowLevelMouseProc, and Raw Input seemingly offers simpler access. Very thankful to have some time-saving guidance. Thank you so much for sharing.

1. Foreground quit working once the app went into the background (stayed there)
2. IMessageFilter was not implemented properly

Note: IMessageFilter doesn't work with WPF applications.

It is VERY likely that this is the last update to this code.
It never was the intent of this code to handle messages. I have added the implementation of IMessageFilter as a step in that direction after doing a bit of Googling.

I find it amusing that I am still getting questions on this code 8 years later.
Most of the question are related to the handling of keystrokes.
Rawinput does NOT have a mechanism for this.

I don't or haven't used this code. I wrote it originally for an open source media center.
The changes and additions where added because of user request.

I can't thank you enough for posting this solution. Not only is it exactly what I needed but it all worked flawlessly.

I have a credit card reader on a USB port being managed via WPF. PreviewKeyDown() will happily sense input from the card reader (it's XML starting with DvcMsg) and buffer the entire card info which includes encrypted data. The problem for me was if a user accidentally hits a key on the standard keyboard while the card reader is sending data that key gets embedded in the card info! Such a pity PreviewKeyDown will not report which device sent the data.

I have spent four days on this issue following dead-ends before finding your solution which solved the problem in a matter of a few hours for me. I was researching usb and hid methods but those are dead-ends because while the card reader plugs into the usb port it is not managed by winusb. Further the new Windows 8.1 Windows.Devices library specifically excludes managing keyboard-like devices.

So I'm trying to direct from different keyboards to individual textboxes. Is there an easy way to cancel the keypress if I've already handled it that I'm just blind and missing? It's also important to treat the default keyboard normally. Each additional keyboard is assigned a textbox of its very own.

Hi, any solution? I'm trying to use multiple numberpads and I'm trying to handle the keypresses done on Keypad No.2 then block the input so it won't reach any open windows. Anybody knows how to block the input? Thank you in advance