Maxim Devaev <mdevaev@xxxxxxxxx> writes: >> Felipe Balbi <balbi@xxxxxxxxxx> writes: >> >> yeah, I don't see any issues with this. If you have access to the tool, >> mind running USBCV on the f_hid gadget? Would be cool to get some >> confirmation that we're within spec. > > Thanks for pointing to USBCV. I used a hardware USB protocol analyzer > to understand what was wrong with f_hid, and my hosts only sent idle=0. > Thanks to the test, I realized that I should only use the upper byte > that contains duration. Here a fixed version of the patch, > which successfully passes all HID tests. The idle part: > > Now Starting Test: HID Class GET/SET Idle Test (Configuration Index 0) > Start time: Jul 22, 2021 - 20:29:40 > No report IDs found in report descriptor for Interface : 0x0 > GET/SETIdle test for report ID 0. Setting Idle rate to : 0x7F > No report IDs found in report descriptor for Interface : 0x1 > GET/SETIdle test for report ID 0. Setting Idle rate to : 0x7F > > Stop time: Jul 22, 2021 - 20:29:41 > Duration: 1 second. > Stopping Test [ HID Class GET/SET Idle Test (Configuration Index 0): > Number of: Fails (0); Aborts (0); Warnings (0) ] > > > From ac56ddc1ab2dfa599a12a3bf064e520d587e89fe Mon Sep 17 00:00:00 2001 > From: Maxim Devaev <mdevaev@xxxxxxxxx> > Date: Wed, 21 Jul 2021 20:48:28 +0300 > Subject: [PATCH] usb: gadget: f_hid: added GET_IDLE and SET_IDLE handlers > > The USB HID standard declares mandatory support for GET_IDLE and SET_IDLE > requests for Boot Keyboard. Most hosts can handle their absence, but others > like some old/strange UEFIs and BIOSes consider this a critical error > and refuse to work with f_hid. > > This primitive implementation of saving and returning idle is sufficient > to meet the requirements of the standard and these devices. > > Signed-off-by: Maxim Devaev <mdevaev@xxxxxxxxx> Great, thank you. Acked-by: Felipe Balbi <balbi@xxxxxxxxxx> -- balbi
Attachment:
signature.asc
Description: PGP signature
