Sorry, my email client decided to send that email as HTML.
Here is the contents as plain text:
On 13/06/12 11:13, Toby Gray wrote:
Hi,
I've been trying to use libusbx to connect to an Android device via
the Android Open Accessory protocol. The Windows machine (as USB host)
is treated as an accessory to the Android device.
Details of the protocol can be found here:
http://developer.android.com/guide/topics/usb/adk.html#accessory-protocol
The problematic step I'm having is with the SET_CONFIGURATION
described in " Establish communication with the device"
libusbx currently will automatically complete any attempt to set the
configuration to the currently active configuration. This is
problematic as it means the device never sees the SET_CONFIGURATION
message.
The attached patch fixes this by allowing the SET_CONFIGURATION
message to be sent on the bus if it matches the currently active
configuration.
Would this be a change considered for inclusion in v1.0.13 of libusbx?
Or is there a reason for the current behavior, other than just
avoiding unnecessary bus activity?
The rest of this email is some extra information about the Android
Open Accessory protocol and why the device needs to see the
SET_CONFIGURATION transfer.
You might be wondering why the Android device needs to see multiple
SET_CONFIGURATION messages, as Windows will have sent it one when
configuration the device when it was first plugged in. The reason for
this is that the Android side API for the Android Open Accessory
Protocol looks like a socket based API.
Once you've opened, used and then closed the accessory (in your
Android code) on the device then you can't open the accessory again
until the device has sent another SET_CONFIGURATION message.
Regards,
Toby
>From d5bd000d0d5db5d71cb29d280860acbdc511e919 Mon Sep 17 00:00:00 2001
From: Toby Gray <toby.g...@realvnc.com>
Date: Wed, 13 Jun 2012 10:29:48 +0100
Subject: [PATCH] Windows: Enable SET_CONFIGURATION control transfers for the
current configuration.
Prior to this fix attempts to SET_CONFIGURATION to the current active
configuration would always succeed but would not generate any bus activity.
Behaviour when attempting to set the configuration to anything other
than the active configuration has not changed.
Some USB devices use receiving of SET_CONFIGURATION to perform some
operation, such as the Android Open Accessory
(http://developer.android.com/guide/topics/usb/adk.html#accessory-protocol).
---
libusb/os/windows_usb.c | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/libusb/os/windows_usb.c b/libusb/os/windows_usb.c
index 98b26eb..a083ef3 100644
--- a/libusb/os/windows_usb.c
+++ b/libusb/os/windows_usb.c
@@ -2691,14 +2691,11 @@ static int winusb_submit_control_transfer(struct usbi_transfer *itransfer)
// Sending of set configuration control requests from WinUSB creates issues
if ( ((setup->request_type & (0x03 << 5)) == LIBUSB_REQUEST_TYPE_STANDARD)
- && (setup->request == LIBUSB_REQUEST_SET_CONFIGURATION) ) {
- if (setup->value != priv->active_config) {
- usbi_warn(ctx, "cannot set configuration other than the default one");
- usbi_free_fd(wfd.fd);
- return LIBUSB_ERROR_INVALID_PARAM;
- }
- wfd.overlapped->Internal = STATUS_COMPLETED_SYNCHRONOUSLY;
- wfd.overlapped->InternalHigh = 0;
+ && (setup->request == LIBUSB_REQUEST_SET_CONFIGURATION)
+ && (setup->value != priv->active_config) ) {
+ usbi_warn(ctx, "cannot set configuration other than the default one");
+ usbi_free_fd(wfd.fd);
+ return LIBUSB_ERROR_INVALID_PARAM;
} else {
if (!WinUsb_ControlTransfer(wfd.handle, *setup, transfer->buffer + LIBUSB_CONTROL_SETUP_SIZE, size, NULL, wfd.overlapped)) {
if(GetLastError() != ERROR_IO_PENDING) {
--
1.7.9
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
