[U-Boot] [PATCH] usb: kbd: don't use int xfers when polling via ctrl xfers

[Hans de Goede]

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 <swarren at 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 <hdegoede at redhat.com>
>>> Signed-off-by: Stephen Warren <swarren at 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.

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