All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] usb: kbd: don't use int xfers when polling via ctrl xfers
Date: Mon, 16 Nov 2015 10:16:18 -0700	[thread overview]
Message-ID: <564A0F62.9060406@wwwdotorg.org> (raw)
In-Reply-To: <5648DFBD.3060004@redhat.com>

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

  reply	other threads:[~2015-11-16 17:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-13 20:34 [U-Boot] [PATCH] usb: kbd: don't use int xfers when polling via ctrl xfers Stephen Warren
2015-11-14  1:16 ` Marek Vasut
2015-12-15 23:35   ` Stephen Warren
2015-12-16  0:42     ` Marek Vasut
2015-12-16  2:45       ` Stephen Warren
2015-12-16 14:13         ` Marek Vasut
2015-11-15 19:40 ` Hans de Goede
2015-11-16 17:16   ` Stephen Warren [this message]
2015-11-16 17:20     ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=564A0F62.9060406@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.