On Mon, 25 May 2015, Golmer Palmer wrote: > 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. No, it isn't. You said "several Keyboard and Mouse implementations using this framework are in fact fully compatible with BOOT mode." This means that other implementations are _not_ compatible with Boot mode. The assumption is _sometimes_ true and _sometimes_ false. > 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. But then the driver would do the wrong thing in cases where the program is not compatible with the Boot protocol. > > 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. The reason for not implementing the change is because the change _will_ cause trouble in cases where the protocols are not the same. If there was some way for the program to tell the driver that it was compatible with both protocols, then the driver could safely implement the change. But there is no way for the program to do this. Alan Stern -- 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
