It JUST is a copy.(About Keyboard Driver)

From this, we can conclude that kbdclass is a class filter driver. Other examples of class filter drivers are mouclass (for mice) and irenum (for infrared devices).

The other type of class driver is a driver which implements a certain class specification for a particular type of device. This type of driver is usually written by Microsoft and will be the default in box driver for the type of device the driver controls. So in this case, class refers to the specification class of the device, not the device's class as specified by an INF. Typically the class driver is installed based off of a compatible ID for the device rather then a hardware ID. Examples of class drivers in Windows are hidusb (USB HID device), bthusb (Bluetooth HID device), usbstor (USB mass storage), usbccid (USB smart card reader), i8042prt (for PS2 mice and keyboards), and serial (COM port). Also, just because a driver may be a class driver does not limit it to being only an FDO, it can also be a bus driver as well if it needs to be.

To tie it all together, let's look at a PS2 keyboard stack and see the class "role" for each device object in the stack

+----------+
| kbdclass |  <-- class filter driver
+----------+
     |
+----------+
| i8042prt | <-- class driver (also the FDO)
+----------+
     |
+----------+
|   PDO    |
+----------+

In conclusion, class filter drivers are loaded based on the installed device class (as specified by the INF). A class driver is typically the FDO in a stack who implements an industry standard interface to a particular type of device. The difference between the two names only makes a difference when the device stack is built up. Once the device stack has been built (e.g. every driver's AddDevice has been called), Windows treats all devices in the stack the same way.