Alan Stern <stern@...> writes: > > On Tue, 26 May 2015, Golmer Palmer wrote: > > > Alan Stern <stern <at> ...> writes: > > > > So please, can you add also some minimal support inside Set_Protocol() > > to "change" from mode "0" to mode "1" (and viceversa) assuming that both > > modes are equal? > > Okay, a revised patch is below. Let me know how it works out. >
Hi Alan, Thank you for the new patch! However, a comment: * At page 74 of the specifications, section F.3 Boot Keyboard Requirements, (http://www.usb.org/developers/hidpage/HID1_11.pdf) is defined that: "The Boot Keyboard shall, upon reset, return to the non- boot protocol which is described in its Report descriptor. That is, the Report descriptor for a Boot Keyboard does not necessarily match the boot protocol. The Report descriptor for a Boot Keyboard is the non-boot protocol descriptor. " This enforces that the default mode (protocol) is REPORT, not BOOT. So why initialize in the patch to "1" for devices without boot support and "0" for devices with boot support? I suggest to always initialize to "1" (=REPORT mode). Remember that the assumption is that the DESCRIPTOR of the BOOT protocol is IDENTICAL to the descriptor of the REPORT protocol, so they are the same. This is the key point! Moreover, if a device don't supports BOOT mode, then the function Get_Protocol() needs to be unimplemented. See page 54, section 7.2.5 Get_Protocol Request. So, I suggest to maintain the old behaviour ("goto stall" for returning ERROR) in the Get_Protocol() in case of bInterfaceSubClass != USB_INTERFACE_SUBCLASS_BOOT. This can be in the same way as you done in the Set_Protocol function. Regards! GP. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
