Alan Stern <stern@...> writes: > > 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.
Yes. You're right. And you put the solution in your patch: if the descriptor of the device contains the USB_INTERFACE_SUBCLASS_BOOT then this device has implemented the BOOT protocol. If not listed as boot compatible, then no option for working in BOOT mode. The assumption about I speak is this: implementations that advertise as BOOT compatible AND are using a DIFFERENT implementation for BOOT and REPORT modes are... INEXISTENT. This type of implementations don't exists in the Linux gadget land because with the current driver is impossible to change from REPORT to BOOT (remember that the function Set_Protocol() *always* return ERROR). Then this case can be put out-of-scope. In any case can be possible to modify the code to include a define option for enable it. But the current case is that neither implementation with boot=report and boot!=report can work because the lack of Set_Protocol() and Get_protocol(). So the best, at minimum, is support the most common case (boot=report). Personally, I only know a very few devices that supports the report mode with expanded functions and supporting also the boot mode. Mainly advanced keyboards (multi-key) that all of them are implemented using custom stacks (not the Linux gadget). So this a very *uncommon* case. > > 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. This is impossible if the devices advertises as BOOT compatible. Your patch includes this check, so the problem is solved. > > > 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. Yes. But I explained that this is a very uncommon case... and if you refuse to enable the change you're in fact breaking the specifications. They say that the REPORT mode is the default when connecting the device to the USB port. Then to enable the BOOT mode the function Set_Protocol() needs to be used. So if you don't implement the change, some clients refuse to work with the device. From my point of view the specification should have to define different: default is BOOT if it's advertised and REPORT after change. But they suggested in this way because the change is minimal if you don't use the BOOT mode... and the people that created the specification has view the BOOT mode as an ENHANCEMENT. Remember that the key questions is: typically "BOOT mode"=="REPORT mode". So no difference at all (please, review the specifications if you don't believe me). I spend several weeks to found this trouble. And the result is that is extremely uncommon to found devices supporting the BOOT mode and using an extended REPORT mode. So, the first is fully support the BOOT mode, and then if someone needs it to support an extended REPORT mode. > 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. Correct. When someone needs this in the future a new function for enable it should needed in the kernel driver. But for fully support the BOOT mode a simple implementation of the Set_Protocol() and Get_Protocol() are the only requirement. 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? Thank you Alan for your support and comments. I really appreciate them! 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
