From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Mon, 16 Nov 2015 18:20:58 +0100 Subject: [U-Boot] [PATCH] usb: kbd: don't use int xfers when polling via ctrl xfers In-Reply-To: <564A0F62.9060406@wwwdotorg.org> References: <1447446849-10438-1-git-send-email-swarren@wwwdotorg.org> <5648DFBD.3060004@redhat.com> <564A0F62.9060406@wwwdotorg.org> Message-ID: <564A107A.9010103@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 16-11-15 18:16, Stephen Warren wrote: > On 11/15/2015 12:40 PM, Hans de Goede wrote: >> Hi, >> >> On 11/13/2015 09:34 PM, Stephen Warren wrote: >>> From: Stephen Warren >>> >>> When CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP is enabled, use a >>> GET_REPORT control transfer to retrieve the initial state of the >>> keyboard. This matches the technique used to poll the keyboard state. >>> This is useful since it eliminates the remaining use of interrupt >>> transfers from the USB keyboard driver, which allows it to work with >>> USB HCD that don't support interrupt transfers. >>> >>> Cc: Hans de Goede >>> Signed-off-by: Stephen Warren >>> --- >>> Are there any disadvantages to using control transfers over interrupt >>> transfers? I'm not aware of any, but I assume there must be a reason >>> that U-Boot typically uses interrupt transfers. >> >> I know of at least 2 issues with using control transfers, and IMHO we >> should try to just remove support for control transfers from the usb >> kbd drivers. >> >> The 2 known issues are: >> >> 1) I've some cheap wireless keyboards where the usb-dongle does not >> support the ctrl method of polling and things simply do not work >> when using it. >> >> 2) My USB+DVI kvm switch will report keys as pressed to all connected >> machines, even those without focus when using the ctrl method (this makes >> sense since other control methods must work without focus to keep the >> os on the machine happy). > > Interesting; Marek observed the opposite i.e. some keyboards that only worked with control transfers. Right, that is likely due to a broken host-driver implementation for irq endpoints in u-boot, rather then due to broken hardware though. All significant operating systems by default use interrupt endpoints for keyboards, so a keyboard where those are broken will not sell well. > However, I think that fixing the existing "use control transfers" support so that it exclusively uses control transfers is still reasonable? Ack, as long as we have it, we should fix it. I do believe we should get rid of it in the long run though. > Perhaps the issues with control transfers affect my decision not to implement interrupt transfers at all in my USB driver, but probably not this patch. > > Perhaps a useful future extension would be to register two keyboard drivers; one explicitly using interrupt transfers and one using control transfers, so that the user can set stdin depending on which mode of operation they want. I do not think that that is necessary. As said I believe that any problems with interrupt transfers are host-driver issues, not hardware issues so they can be fixed. Where as the issues with ctrl transfers are hardware issues which cannot be worked-around. Regards, Hans