Specifications

Remote Control and Receiver-Transceiver Specifications and Requirements
for Windows Media Center in Windows Operating Systems
138
Additional protocol support
The version 2 class driver adds support for a newer remote control protocol. The SMK Quatro
Pulse protocol is now available as an option for remote controls manufacturers. Contact
[e-mail] for details about licensing this protocol. In June 2009, all receiver
partners must be able to handle both the MC RC 6 and the MC SMK QP protocol per the
Windows Logo Program.
Dynamic wake programming
Hardware devices need to operate in extremely low-power situations while waiting for the Sleep
toggle or Wake button to turn the PC back on. In this low-power state, the hardware is often only
capable of watching for a single IR signature to wake the system. Because there are a wide
variety of options available for protocol and Sleep-button combinations (Sleep toggle versus
discrete Wake/Sleep), the system must be able to program the hardware dynamically to wake on
the correct Sleep button. The version 2 DDI adds a set of IOCTLs and capabilities flags to control
dynamic wake programming.
Dynamic active input device selection
The previous implementation of the IR class driver relied on the concept of an active input device.
This concept was used to prevent the host from receiving multiple key presses if multiple IR
receivers were present on the system. The heuristic used to determine which IR receiver was the
active IR receiver relied on the order of PNP events and was difficult for the end user to
comprehend. The version 2 class driver relies on a more dynamic mechanism to filter out
duplicate input if multiple receivers are present. With the version 2 class driver, there is no need
to switch the active input device because all IR receivers are active with the class driver filtering
out duplicate input.
Receiver capabilities: input only on long-range receiver
A partner may want to build a receiver device that uses a long-range receiver part with a narrow
band pass filter (BPF). This long-range receiver would allow IR input to function correctly, but
would not allow parse-and-match to function correctly.
Receiver capabilities: no input on long-range receiver
An OEM partner may want to build a receiver device that uses the long-range receiver part for
parse-and-match, but not for IR input. This might be desirable because the partner may be
distributing this receiver with a non-IR remote. In this case, the long-range receiver would be
used for parse-and-match operation, but not for IR input operation.
Receiver capabilities: no long-range receiver
An OEM partner may want to build a receiver device that does IR blasting and IR learning, but
they don't want to put a long-range receiver in it because remote control input is done using a
different device.
Receiver capabilities: no receiver at all (blasting only).
An OEM partner may want to build an IR device that doesn't do any IR receiving. This device
might only do IR blasting. This would be desirable for partners whose hardware might be with the
TV tuner hardware in a position where IR reception would be impossible (such as in a closet or in
the back of the PC).
Notes on the Updated Emulator Interface
In addition to the version 2 DDI, a newer IR emulator interface is also being published. This
newer emulator interface is related to version 2 DDI in that it defines the emulator protocol