First, there are class filter drivers. These drivers
are loaded based on the device's installed device class.
This is the same device class that you specify in your INF when you install the device. These
drivers are loaded by the registry value named "UpperFilters" or "LowerFilters". Each
class, as specified by a GUID, has its own set of these values. These classes can be found in
the registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class.
Let's take the keyboard class as an example. In your INF which installs a keyboard,
you have the following:
"UpperFilters" : REG_MULTI_SZ : "kbdclass"
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 |