Missing USB HID Filter Sample in Windows-driver-samples for Custom USB HID Key Remapping

Question

Hello Microsoft Driver Development Team,

I hope you are well.

I am currently developing a kernel-mode driver on Windows using the Windows Driver Kit (WDK). Specifically, I need to implement a USB HID keyboard filter driver that remaps certain non-standard HID usage codes from a custom keyboard to standard HID usage codes.

For example, my keyboard sends 0xA4 when the A key is pressed, but the standard HID usage for A is 0x04. I need to intercept the input reports at the driver level and remap 0xA4 to 0x04 before the HID data reaches kbdhid.sys and kbdclass.sys.

I have reviewed the kbfiltr sample in the official Windows-driver-samples repository:

https://github.com/microsoft/Windows-driver-samples/tree/main/input/kbfiltr#universal-windows-driver-compliant

However, this sample is clearly written for PS/2 keyboards (using IOCTL_INTERNAL_KEYBOARD_CONNECT and KEYBOARD_INPUT_DATA), and does not support USB HID keyboards. I have not found an equivalent sample for USB HID keyboard filtering or remapping in the repository or documentation.

My questions are:

Is there an official Microsoft sample  for a USB HID keyboard filter driver that demonstrates how to intercept and modify HID input reports for remapping usage codes?

Is IOCTL_HID_READ_REPORT the correct interception point for modifying USB HID keyboard reports, and if so, are there recommended best practices to avoid compatibility issues?

Are there any constraints or guidelines Microsoft recommends when modifying HID input reports for keyboard remapping at the driver level?

For reference, I need to support the standard USB HID keyboard class, not just PS/2, and the goal is to remap custom HID usages to their standard values at the driver layer.

Answer 1

Hi @Gowtham T ,

Thank you for sharing the details!

---

Is there an official Microsoft sample  for a USB HID keyboard filter driver that demonstrates how to intercept and modify HID input reports for remapping usage codes?

Unfortunately, Microsoft does not provide an official sample that filters or remaps USB HID keyboard input reports. Microsoft samples related to keyboard filtering are intentionally scoped to demonstrate driver models or PS/2 patterns, not USB HID keyboard usage remapping just like you mentioned.

For USB keyboards, Microsoft documentation assumes devices emit correct standard HID usages and does not include a reference implementation for modifying keyboard HID reports.

Perhaps you could find some useful info here: HID architecture

---

Is IOCTL_HID_READ_REPORT the correct interception point for modifying USB HID keyboard reports, and if so, are there recommended best practices to avoid compatibility issues?

From my understanding, IOCTL_HID_READ_REPORT is part of the HID class driver I/O contract and is not documented as a supported interception point for externally modifying keyboard input.

For USB HID keyboards, any report modification would need to occur inside a properly written HID upper filter driver attached to the HID device stack, and only on raw HID input reports before they are interpreted by kbdhid.sys. Intercepting or modifying reports outside the HID stack is not recommended and can lead to lost input, timing issues, or undefined behavior. For IOCTL reference (transport, not remapping guidance): IOCTL_HID_READ_REPORT IOCTL (hidport.h)

---

Are there any constraints or guidelines Microsoft recommends when modifying HID input reports for keyboard remapping at the driver level?

I believe Microsoft does not recommend kernel‑mode keyboard remapping as a general solution. The documented guidance consistently favors:

• Devices sending correct, standard HID usage codes from firmware
• Avoiding kernel‑mode mutation of keyboard semantics due to compatibility, accessibility, security, and certification risks

When modification is unavoidable for specialized hardware, it is treated as a vendor responsibility with no long‑term compatibility guarantees. Microsoft provides no endorsement or sample for keyboard usage remapping and warns that such approaches can break accessibility features, IME behavior, secure input paths, and future Windows releases.

Reference:

• Keyboard HID client guidance (role boundaries): Developing keyboard and mouse HID client drivers
• Virtual alternative (supported injection model): Write a HID source driver by using Virtual HID Framework (VHF)