Author Topic: Ctrl transfer AOA v2 and PyUSB  (Read 15739 times)

cb

  • Member
  • ***
  • Posts: 6
Ctrl transfer AOA v2 and PyUSB
« on: May 10, 2020, 10:19:41 pm »
Hi All, even though my Samsung Galaxy S9 support the AOA v2.0 version, I am unable to get it re-enumerated as a AOAv2 device through a control transfer request.

Following instructions in https://source.android.com/devices/accessories/aoa I am able to confirm that my Samsung S9 supports AOA v2.0 by issuing the following control request and I get the return as "2".
Code: [Select]
ret = ldev.ctrl_transfer(0xC0, 51, 0, 0, 2)
print ("\n2. Protocol version: {}".format(ret[0]))

However, following the instructions in https://source.android.com/devices/accessories/aoa2 I am unable to get my Samsung s9 re-introduce as a device with any one of the 0x2D02, 0x2D03, 0x2D04, 0x2D05 PIDs.
Code: [Select]
ret = ldev.ctrl_transfer(0x40, 54, 0x01, len(descriptor_str), "")
The Samsung S9 is not changing its VID/PID and re-introducing itself as a AOAv2 accessory. The return value is '0' which I am interpreting as 'True'.

I do not have any issues with AOAv1. I am able to get my Samsung s9 successfully re-introduced as an AOA v1 accessory with a PID of 0x2D01 by the following code. I was also able to successfully write an android app and exchange data back and forth using the bulk endpoints.
Code: [Select]
ret = ldev.ctrl_transfer(0x40, 53,0, 0, None) 
Even though my Samsung S9 says it is supporting AOAv2, why is it not changing and reintroducing as a AOAv2 accessory when issued with control transfer request? Is there anything wrong with my ctrl_transfer statement? Why does it work with AOAv1 and not AOAv2?

Thank you so much for your assistance.

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: Ctrl transfer AOA v2 and PyUSB
« Reply #1 on: May 11, 2020, 10:59:09 am »
I don't know the reason. Try the HID request with 0x2D01? See:

https://stackoverflow.com/questions/26574707/android-simulating-hid-keyboard

Also

"Product IDs used in AOAv1 (0x2D00 and 0x2D01) continue to be supported in AOAv2."

cb

  • Member
  • ***
  • Posts: 6
Re: Ctrl transfer AOA v2 and PyUSB
« Reply #2 on: May 11, 2020, 05:17:38 pm »
Try the HID request with 0x2D01?

No luck  :( Once the devices is reintroduced as 0x2D01 only IN and OUT BULK endpoints are available. No interrupt endpoints are available.

The way I understand the current AOA documentation, to get HID endpoints, I need 0x2D04 or 0x2D05. And my phone does not respond to a control request to change the device to either 0x2D04 or 0x2D05 and get HID endpoints :(

Only Bulk endpoints are available with 0x2D00 and 0x2D01.


Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: Ctrl transfer AOA v2 and PyUSB
« Reply #3 on: May 11, 2020, 08:03:55 pm »
My interpretation of this is that the HID interface doesn't use interrupt endpoints:

From:

https://source.android.com/devices/accessories/aoa2

AOAv2 adds new USB control requests that allow the accessory to act as one or more HID input devices to the Android device. HID support is handled entirely through control requests on endpoint zero, so no new USB interface is needed.

cb

  • Member
  • ***
  • Posts: 6
Re: Ctrl transfer AOA v2 and PyUSB
« Reply #4 on: May 19, 2020, 04:05:23 am »
My interpretation of this is that the HID interface doesn't use interrupt endpoints:

Yes, I can now confirm that this is the case. The HID interface in this case does not use interrupt endpoints and just use control transfer for data exchange. I managed to simulate a keyboard using control transfer.

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: Ctrl transfer AOA v2 and PyUSB
« Reply #5 on: May 21, 2020, 08:46:30 am »
Thanks for reporting back. Control transfers aren't efficient but can work for some applications.

Renate

  • Frequent Contributor
  • ****
  • Posts: 97
Re: Ctrl transfer AOA v2 and PyUSB
« Reply #6 on: May 28, 2020, 09:51:10 am »
I'll just add the caveat that AoA support is very spotty and arbitrary.
I've tried it with a bunch of devices here and none work correctly.
Some don't respond to version request, which is correct for non-supporting devices.
Some respond 2.0 but don't disconnect/reconfigure on the accessory command (they ACCEPT).
Some renumerate correctly but don't support the register HID command (they STALL).
And although some report that they can register HID without going into accessory mode, I've not seen it.
And finally, they deprecated the audio mode.