How Windows recognizes custom keyboard and mouse input devices

Question

Hi, Im working on a small hardware project for our office lab where I wannna build a custom keyboard and mouse completely from scratch, including designing the PCB and firmware. The part im stuck on is understanding how Windows actually detects and communicates with input devices - like what protocol or signals the laptop expects when something plugs in USB. I need this to integrate with our company systems properly, but right now im kinda lost on what exact input standards or interfaces Windows requires for keyboards and mice to be recognized. Any guidance would be really helpfull.

Answer 1

Dear Jimmy X,

Thank you for reaching out with your question about how Windows detects and communicates with input devices such as keyboards and mice. When a device is connected via USB, Windows relies on the USB Human Interface Device (HID) class specification. This standard defines how input devices present themselves to the operating system, including descriptors that describe the device’s capabilities. Windows uses these descriptors to automatically load the appropriate HID drivers, which handle communication between the hardware and the operating system. For a custom keyboard or mouse project, the critical step is ensuring that the firmware implements the USB HID class correctly. By conforming to the HID specification, the device will be recognized by Windows without requiring additional drivers. The HID protocol covers standard input reports for keyboards and mice, and Windows expects devices to follow these conventions. If this answer resolves your concern, please click Accept the answer to support my answer.

Thank you so much!!!

Best regards,

QQ.

Answer 2

Windows expects keyboards and mice to appear as standard USB (or Bluetooth, etc.) Human Interface Devices (HID). If the device’s USB descriptors and HID report descriptors conform to the HID usage tables for keyboard and mouse, Windows will automatically bind its in-box drivers and the device will work without any custom driver.

Key points for a custom keyboard/mouse over USB:

1. HID device class
   • Implement the USB HID class on the device.
   • Use the standard HID usage pages and usages for keyboard and mouse:
     • Keyboard: HID usage page for Generic Desktop / Keyboard usages.
     • Mouse: HID usage page for Generic Desktop / Pointer / Mouse usages.
   • Define one or more top level collections (TLCs) in the HID report descriptor:
     • A pure keyboard can expose a keyboard TLC.
     • A pure mouse can expose a mouse TLC.
     • A combo device (keyboard with integrated pointing device) exposes multiple TLCs (for example, one for keyboard, one for mouse). Windows will create a separate PDO (logical device) for each TLC.
2. How Windows builds the driver stack
   • The USB transport stack enumerates the device and creates a physical device object (PDO), then loads the HID transport driver and HIDCLASS.sys (the HID class driver).
   • HIDCLASS.sys parses the HID report descriptor and creates a PDO for each keyboard or mouse top level collection.
   • For each keyboard TLC, Windows loads KBDHID.sys (HID keyboard mapper driver), which converts HID usages into keyboard scan codes.
   • For each mouse/touchpad TLC, Windows loads MOUHID.sys (HID mouse mapper driver), which converts HID usages into mouse movement/buttons/wheel commands.
   • KBDHID.sys then loads KBDCLASS.sys (keyboard class driver), which provides the OS-level keyboard functionality.
   • MOUHID.sys then loads MOUCLASS.sys (mouse class driver), which provides the OS-level mouse functionality.
   • As long as the device presents a valid HID keyboard/mouse TLC, no vendor-specific driver is required.
3. No vendor driver needed if HID-compliant
   • For standard keyboard and mouse behavior, vendor drivers are not required if the device is compliant with the supported HID usages and top level collections.
   • This means the firmware must:
     • Expose correct USB device/interface descriptors for HID.
     • Provide a correct HID report descriptor describing keyboard and/or mouse reports.
     • Send input reports that match the descriptor (for key presses, releases, mouse movement, buttons, wheel, etc.).
4. Keyboard layout vs. hardware
   • The physical key matrix and scan codes are abstracted by Windows.
   • KBDHID.sys maps HID usages to scan codes; KBDCLASS.sys and the configured keyboard layout map scan codes to characters.
   • The “layout” (language, key labels, etc.) is configured in Windows, not in the device firmware. The device just needs to send the correct HID usages for each key.
5. Accessing raw input in applications (optional)
   • Applications that need device-specific data can use the Raw Input API.
   • In the traditional model, Windows converts device-specific data to device-independent messages (for example, WM_CHAR, WM_MOUSEMOVE).
   • With Raw Input, applications register for devices and receive raw HID data via WM_INPUT, allowing them to distinguish between multiple keyboards/mice and process low-level data directly.
   • This does not change how the hardware must present itself; it still needs to be a proper HID keyboard/mouse for Windows to enumerate it as such.
6. Other transports
   • HID is bus-agnostic. The same HID model applies over USB, Bluetooth, and other supported transports.
   • On Windows, HIDCLASS.sys is the glue between the HID client drivers (keyboard/mouse mappers) and the various transports.
7. If a non-standard protocol is used
   • If the device does not conform to HID keyboard/mouse usages, Windows will not treat it as a standard keyboard or mouse.
   • In that case, a custom driver (for example, using WinUSB or a vendor-specific driver) and custom software would be required, but it would no longer behave as a system keyboard/mouse.

For a lab-built keyboard/mouse that “just works” on Windows and integrates with existing systems, the practical path is:

1. Implement USB HID class in firmware.
2. Use standard HID usage pages/usages for keyboard and mouse.
3. Define correct HID report descriptors for keyboard and/or mouse TLCs.
4. Ensure reports match the descriptors.

Windows will then automatically load HIDCLASS.sys, KBDHID.sys/MOUHID.sys, and KBDCLASS.sys/MOUCLASS.sys, and the device will be recognized as a normal keyboard and/or mouse.

---

References:

• Developing keyboard and mouse HID client drivers
• Keyboard layout
• Raw Input Overview
• Develop Windows device drivers for Human Interface Devices (HID)
• Sample Device and Driver Configuration
• Interfacing with the different GameInput device types
• Overview of building USB devices for Windows