Introduction to the CIRClass Framework

Infrared deprecation warning

The CIRClass driver is the interface between drivers that support one or more Microsoft Windows CIR devices and the rest of the Windows operating system. The CIRClass driver provides a framework that centralizes common processing and simplifies the creation of CIR Port drivers. To help describe that framework, consider how CIRClass supports and interfaces with the USBCIR driver that Microsoft supplies. The following diagram shows the relationship between the device objects that these two drivers create.

In the preceding diagram, each device object is represented by a circle or a square. Circles represent functional device objects (FDOs) and squares represent physical device objects (PDOs). The driver that creates each device object is shown on the left of the diagram, on the same line as the device object that it creates. The solid lines in the diagram shows which device objects are attached.

Note   Only the device objects that are directly relevant to CIRClass and USBCIR are shown in the preceding diagram.

In the diagram, note that CIRClass and USBCIR are separate drivers, each with its own FDO. While not specifically shown in the preceding diagram, there is only one instance of the CIRClass driver (and one CIRClass FDO), no matter how many CIR Port drivers are installed on a system. Thus, CIRClass does not provide a minidriver-based framework like the framework that is provided by, for example, the HIDClass or StorPort drivers. Instead, CIRClass supports CIR Port drivers that are independent function drivers. Thus, CIR Port drivers are entirely responsible for controlling their hardware and act as the power policy owner for their hardware devices.

CIR Port drivers are instantiated by the Windows Plug and Play (PnP) manager after the hardware device that they support is detected. For example, the USBCIR driver is instantiated when the (standard Microsoft-supplied) USBHUB driver detects that a supported USBCIR remote control device has been plugged in. Thus, when the USBHUB driver detects a USBCIR remote control device, it creates a PDO that describes this device and informs the PnP manager of the device's existence. The PnP manager then loads the appropriate function driver for the CIR device. In the preceding diagram, the driver that is loaded as a result of this action is the USBCIR driver. When USBCIR starts, it creates an FDO and attaches that FDO to the underlying device stack, according to the standard Windows practice.

Even though the CIRClass driver is available on all Windows systems, it is not installed until a CIR Port driver is installed. Whenever a CIR Port driver is installed, a device-specific coinstaller is called to install and start the CIRClass (if it has not already been installed and started). This device-specific coinstaller, which is provided by Microsoft, must be call by all CIR Port drivers as part of their installation procedure.

There is no direct connection (that is, no attachment) between the CIRClass and USBCIR drivers. As a result, CIRClass engages in a handshaking exchange with each CIR Port driver when that port driver is started.

Send comments about this topic to Microsoft