Alan Stern <stern@...> writes: > > I feel that this person ins't at time maintaining this source code. > > You seem to be right, since his email address doesn't work any more. > > > I'm suposing that this mailing list is readed by very competent people > > that can implement this "simple" change. I hope someone likes to fix > > that problem... > > I took a look at the driver. The change you seem to be asking for is > not simple at all. > > The problem is that the f_hid driver doesn't support either the Report > or Boot protocols. Instead, it relies on a user program to generate or > consume the reports that get sent to/from the host. Currently the > driver has no way to inform the user program about which protocol to > use, and the program has no way to tell the driver when the protocol > is changed. > > Your original email message said: > > > The problem is that several Keyboard and Mouse implementations using this > > framework are in fact fully compatible with BOOT mode. > > As far as I can tell, an implementation can support either the Report > or Boot protocol, but not both. The problem is that when you use a > keyboard or mouse during boot-up, the BIOS will want to use the Boot > protocol, and once the boot-up is complete, the operating system will > want to switch to the Report protocol. Hi Alan, Thank you for your response and the patch. First a comment: Please, take into account that I mentioned that the ASSUMPTION that keyboard and mouse drivers are compatible with BOTH protocols is really TRUE. Then any program that implements keyboard and/or mouse emulation is only implementing the BOOT protocol (6KRO for keyboard and 3button for mouse). The real problem is that the driver don't implements the two needed functions [ Get_Protocol() & Set_Protocol() ], although the program implements the BOOT protocol. Remember that BOOT protocol is only a subset of REPORT protocol; and no one has interest in implementing a more complex keyboard or mouse target. So, the question is why the hid usb gadget driver don't implements these two functions for supporting the BOOT protocol? When the device is compatible with both protocols, the status info reported by the driver is not relevant, and this is the point that I suggest to change: report the change instead what is doing the program, because the two protocols are the same. > The patch below adds support for Get Protocol and Set Protocol, but > only for one protocol at a time (switching is not supported). Does > this do what you want? Related to your patch, if the default mode is BOOT, I feel it can work. However, why not implement the change? If both protocols are the same, the change can be done with any trouble. Regards! -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
