Maxim Devaev <mdevaev@xxxxxxxxx> writes:
> f_hid provides the OUT Endpoint as only way for receiving reports
> from the host. SETUP/SET_REPORT method is not supported, and this causes
> a number of compatibility problems with various host drivers, especially
> in the case of keyboard emulation using f_hid.
>
> - Some hosts do not support the OUT Endpoint and ignore it,
> so it becomes impossible for the gadget to receive a report
> from the host. In the case of a keyboard, the gadget loses
> the ability to receive the status of the LEDs.
>
> - Some BIOSes/UEFIs can't work with HID devices with the OUT Endpoint
> at all. This may be due to their bugs or incomplete implementation
> of the HID standard.
> For example, absolutely all Apple UEFIs can't handle the OUT Endpoint
> if it goes after IN Endpoint in the descriptor and require the reverse
> order (OUT, IN) which is a violation of the standard.
> Other hosts either do not initialize gadgets with a descriptor
> containing the OUT Endpoint completely (like some HP and DELL BIOSes
> and embedded firmwares like on KVM switches), or initialize them,
> but will not poll the IN Endpoint.
>
> This patch adds configfs option no_out_endpoint=1 to disable
> the OUT Endpoint and allows f_hid to receive reports from the host
> via SETUP/SET_REPORT.
>
> Previously, there was such a feature in f_hid, but it was replaced
> by the OUT Endpoint [1] in the commit 99c515005857 ("usb: gadget: hidg:
> register OUT INT endpoint for SET_REPORT"). So this patch actually
> returns the removed functionality while making it optional.
> For backward compatibility reasons, the OUT Endpoint mode remains
> the default behaviour.
>
> - The OUT Endpoint mode provides the report queue and reduces
> USB overhead (eliminating SETUP routine) on transmitting a report
> from the host.
>
> - If the SETUP/SET_REPORT mode is used, there is no report queue,
> so the userspace will only read last report. For classic HID devices
> like keyboards this is not a problem, since it's intended to transmit
> the status of the LEDs and only the last report is important.
> This mode provides better compatibility with strange and buggy
> host drivers.
>
> Both modes passed USBCV tests. Checking with the USB protocol analyzer
> also confirmed that everything is working as it should and the new mode
> ensures operability in all of the described cases.
>
> Signed-off-by: Maxim Devaev <mdevaev@xxxxxxxxx>
> Link: https://www.spinics.net/lists/linux-usb/msg65494.html [1]
Acked-by: Felipe Balbi <balbi@xxxxxxxxxx>
--
balbi
