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 <swar...@nvidia.com>
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 <hdego...@redhat.com>
Signed-off-by: Stephen Warren <swar...@nvidia.com>
---
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.
However, I think that fixing the existing "use control transfers"
support so that it exclusively uses control transfers is still
reasonable? 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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
