This came up recently on the newsgroups. The term "class driver" can mean a couple of different things, depending on the context.

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:

    Class=Keyboard
    ClassGUID={4D36E96B-E325-11CE-BFC1-08002BE10318}
so the corresponding class key for the keyboard device class is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}. Under this key we see the following value:
    "UpperFilters" : REG_MULTI_SZ : "kbdclass"
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.