Specifications

Remote Control and Receiver-Transceiver Specifications and Requirements
for Windows Media Center in Windows Operating Systems
141
On receiving the IOCTL_IR_GET_DEV_CAPS request, the port driver must check the size of the
out buffer. If the out buffer is big enough to hold an IR_DEV_CAPS_V2 structure, the port driver
should assume that it is working with a version 2 class driver. It should fill in the entire
IR_DEV_CAPS_V2 structure, and set the IR_DEV_CAPS_V2.ProtocolVersion member to
DEV_CAPS_PROTOCOL_VERSION_V2 (0x200). If, however, the buffer is only big enough to
hold an IR_DEV_CAPS_V1 structure, the port driver should assume that it is working with a
version 1 class driver. It should fill in the IR_DEV_CAPS_V1 structure and set
IR_DEV_CAPS_V2.ProtocolVersion member to DEV_CAPS_PROTOCOL_VERSION_V1
(0x100). If the buffer is not big enough to hold an IR_DEV_CAPS_V1 structure, the port driver
should fail the IRP.
Proper Implementation of Version 1 and Version 2 Devcaps
The port driver is able to infer the DDI version of the class driver by looking at the size of the
output buffer in the IOCTL_IR_GET_DEV_CAPS request. By adjusting its behavior based on the
version of the DDI, the version 2 port driver is able to work with version 1 class drivers.
Likewise, a version 1 port driver must be able to work with a version 2 class driver. This is only
possible if the version 1 port driver has properly implemented the IOCTL_IR_GET_DEV_CAPS
handler correctly. Namely, the version 1 port driver must accept buffers that are larger than
sizeof(IR_DEV_CAPS_V1) and it must properly set the IR_DEV_CAPS_V1.ProtocolVersion
member to indicate that it subscribes to the (limited) version 1 DDI.
Wake Pattern Programming
When CIRClass wants to direct the hardware to wake on a specific signature, it sends an
IOCTL_IR_SET_WAKE_PATTERN IRP to the port driver. This IRP includes an
IR_SET_WAKE_PATTERN_PARAMS structure, which contains the details of the wake pattern
that the hardware needs to watch for. The port driver is responsible for programming the
hardware to watch for this wake pattern and it should not complete the IRP until the hardware
has been programmed. Because the wake programming may require a moderate amount of I/O
to the device, the port driver may need to return STATUS_PENDING for (to "pend") this IRP
while the programming is taking place.
Alternatively, the hardware may be designed to watch for all valid and required wake patterns. If
so, the port driver can ignore any IOCTL_IR_SET_WAKE_PATTERN IRPS as it already watches
for all required wake patterns.
There are two reasons to change the wake pattern:
 Choice of protocol. Remote controls are available using both the RC6 protocol and the Quatro
Pulse protocol. The wake hardware needs to be programmed to listen for the specific protocol
that is being used by the user‘s remote control.
 Choice of Sleep button. Most current Windows Media Center remote controls offer a single
Sleep button, which can either turn Windows Media Center on or off. This button is called a Sleep
toggle because it toggles the power state. However, the option exists to implement a pair of
discrete Sleep buttons, called discrete Sleep and discrete Wake. The discrete Sleep button will
put the PC into the sleep state, but it won‘t wake it up. The discrete Wake button will wake the
PC, but it won‘t put it to sleep. This is a very desirable feature for power users who want to
program remote control macros that are guaranteed to put the PC into a known state. If the user
has a remote control with a discrete Sleep/Wake button pair, the hardware must be programmed
to wake when the user presses the discrete Wake button.
CIRClass will start with a default wake pattern using the RC6 protocol with a Sleep toggle button,
since this is the most common remote control configuration. During the course of normal