Windows HID设备SET_IDLE请求的寂寞操作

在HID规范中SET_IDLE请求用于节省USB带宽的，使用这个请求可以设置HID设备空闲速率。
不过我们一般抓包的内容是这样的：

 CTL    21 0a 00 00  00 00 00 00                            SET IDLE

这样的

 CTL    21 0a 00 00  01 00 00 00                            SET IDLE

对照HID规范的SET_IDLE的HID请求分析可以知道，这里除了接口描述符的ID不同类，其它都一样，特别是wValue（其高字节用于指定空闲速率，以4ms为单位，可选的值为4ms~1020ms，低字节为ReportId）的值永远是00。

所以说，这玩意有啥用了？没啥用。不过也有一个区别就是固件关于SET_IDLE的响应问题，如果支持，表示该请求成功。如果不支持，会使用BUSHOUND抓包返回一个C0000004的STALL PID错误。不过通过我们之前的文章 Windows系统HID设备的启动过程（http://www.usbzh.com/article/detail-905.html ），这玩意就算错误了，也不是致命性的错误，所以以驱动中，其压根也不进行执行对果的判断。

这里我们结合SET_IDLE请求的代码来看：

   if (DeviceExtension->DeviceFlags & DEVICE_FLAGS_HID_1_0_D3_COMPAT_DEVICE) {
                HumBuildClassRequest(Urb,
                                    URB_FUNCTION_CLASS_ENDPOINT,   // function
                                    0,              // transferFlags
                                    NULL,           // transferBuffer
                                    0,              // transferBufferLength
                                    0x22,           // requestTypeFlags
                                    HID_SET_IDLE,   // request
                                    0,              // value
                                    0,              // index
                                    0);             // reqLength
            } else {
                HumBuildClassRequest(Urb,
                                    URB_FUNCTION_CLASS_INTERFACE,   // function
                                    0,                                  // transferFlags
                                    NULL,                               // transferBuffer
                                    0,                                  // transferBufferLength
                                    0x22,                               // requestTypeFlags
                                    HID_SET_IDLE,                       // request
                                    0,                                  // value
                                    DeviceExtension->Interface->InterfaceNumber,    // index
                                    0);                                 // reqLength
            }

HumBuildClassRequest的宏定义为：

#define HumBuildClassRequest(urb, \
                                       function, \
                                       transferFlags, \
                                       transferBuffer, \
                                       transferBufferLength, \
                                       requestType, \
                                       request, \
                                       value, \
                                       index, \
                                       reqLength){ \
            (urb)->UrbHeader.Length = (USHORT) sizeof( struct _URB_CONTROL_VENDOR_OR_CLASS_REQUEST); \
            (urb)->UrbHeader.Function = function; \
            (urb)->UrbControlVendorClassRequest.Index = (index); \
            (urb)->UrbControlVendorClassRequest.RequestTypeReservedBits = (requestType); \
            (urb)->UrbControlVendorClassRequest.Request = (request); \
            (urb)->UrbControlVendorClassRequest.Value = (value); \
            (urb)->UrbControlVendorClassRequest.TransferFlags = (transferFlags); \
            (urb)->UrbControlVendorClassRequest.TransferBuffer = (transferBuffer); \
            (urb)->UrbControlVendorClassRequest.TransferBufferLength = (transferBufferLength); }

所以说，这里在初始化时的值就是那样，为0。
至于DEVICE_FLAGS_HID_1_0_D3_COMPAT_DEVICE的标识问题，也是因为：

对于HID 1.0草案性，下一个描述符是HID。然而，对于早些时候草稿，端点先出现，然后才是HID描述符。我们正努力支持这两种观点。

所以说，在实际抓包的时候，你会看到，主机还是会按端点描述符定时下发IN请求，只是设备端无数据时，会一直NAK。然后永远的在这个重复过程中。