FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Author Topic: FT90X USB Question: Handling Multiple Keyboard Endpoints (BOOT, NKRO, etc.)  (Read 394 times)

kaspro

  • Newbie
  • *
  • Posts: 5
    • View Profile

I'm making a Keyboard-to-Controller adapter using the FT908. Pretty simple design: You plug a keyboard into one end, and the other end plugs into a Nintendo Switch. From there, you can use your keyboard as a controller.

Right now I'm trying to handle the USB keyboard inputs and this harder than I expected.

Right now I'm using a Corsair K65. It has 3 endpoints and I need to listen to them all simultaneously:
  • A "BOOT" endpoint (where it sends data matching the typical 6-KRO USB report for BIOS)
  • A "Media Controls" endpoint (things like volume up/down)
  • A "NKRO" endpoint (uses a bitmap so you can press ALL THE KEYS!)

I also made a video of me going through the keyboard and asking questions: https://photos.app.goo.gl/7j98istA1GyRfbjE6

The two questions I have:
  • I originally used the "USBH Example HID" code as a starting point, but realized that the "USBH_HID_get_report" is a blocking call to only 1 endpoint (which is a no-go - I need to listen to all 3 endpoints and receive from any as an interrupt.) I found out about "USBH_transfer_async" which seems like what I need. I combined it with looping over "USBH_Process" but it isn't yielding me any data in the buffer I'm sending in. I can't find any code examples using "USBH_transfer_async" - how should I be doing this? Figured this and it's working perfectly (although the documentation says NOT to re-call the "USBH_transfer_async" from within the callback, one of the examples does just that so so far it's been working pretty good)
  • When I do start receiving data, do I need to write unique code to decode all three of those different endpoints? The boot protocol, the volume  All I want is the "keys" sent to me. If I do have to write unique code for each EP, this seems like an impossible task then right? There are hundreds of thousands of keyboards and I assume all of them send different kinds of reports. How could I possibly write code to interpret all of them?? Just looked at my Razer Tartarus and it also has an insanely unique way of reporting keys. HELP!!!

I've attached the USB HID data of my keyboard (interfaces, endpoints, etc.) Hope this helps someone answer my question 🙏
« Last Edit: January 06, 2021, 01:48:18 AM by kaspro »
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 589
    • View Profile

Hello,

If there are 3 endpoints to monitor then the USBH_transfer_async is good way to do it.

You pass in a unique ID (one for each endpoint) and a callback function (the parameters are in the ft900_usbh.h header file).

typedef int8_t (*USBH_callback)(uint32_t id, int8_t status, size_t len, uint8_t *buffer);

There are no examples but it is the same as USBH_transfer except that you get your buffer filled and your callback called during the USBH_Process call. The ID will be used to differentiate the endpoints.

Best Regards,
FTDI Community
Logged

kaspro

  • Newbie
  • *
  • Posts: 5
    • View Profile

Hello,

If there are 3 endpoints to monitor then the USBH_transfer_async is good way to do it.

You pass in a unique ID (one for each endpoint) and a callback function (the parameters are in the ft900_usbh.h header file).

typedef int8_t (*USBH_callback)(uint32_t id, int8_t status, size_t len, uint8_t *buffer);

There are no examples but it is the same as USBH_transfer except that you get your buffer filled and your callback called during the USBH_Process call. The ID will be used to differentiate the endpoints.

Best Regards,
FTDI Community

Thank you so much! I actually solved & nailed the async transfer function (it's working great!)

Right now I'm just trying to figure out how to get the HID Interface Report Descriptors so I can do some parsing on the device. They look like this:

Code: [Select]
Interface 0 HID Report Descriptor Keyboard
Item Tag (Value) Raw Data
Usage Page (Generic Desktop) 05 01
Usage (Keyboard) 09 06
Collection (Application) A1 01
    Usage Page (Keyboard/Keypad) 05 07
    Usage Minimum (Keyboard Left Control) 19 E0
    Usage Maximum (Keyboard Right GUI) 29 E7
    Logical Minimum (0) 15 00
    Logical Maximum (1) 25 01
    Report Size (1) 75 01
    Report Count (8) 95 08
    Input (Data,Var,Abs,NWrp,Lin,Pref,NNul,Bit) 81 02
    Input (Cnst,Ary,Abs) 81 01
    Usage Minimum (Undefined) 19 00
    Usage Maximum 2A FF 00
    Logical Minimum (0) 15 00
    Logical Maximum (255) 26 FF 00
    Report Size (8) 75 08
    Report Count (6) 95 06
    Input (Data,Ary,Abs) 81 00
    Usage Page (LEDs) 05 08
    Usage Minimum (Num Lock) 19 01
    Usage Maximum (Scroll Lock) 29 03
    Logical Minimum (0) 15 00
    Logical Maximum (1) 25 01
    Report Size (1) 75 01
    Report Count (3) 95 03
    Output (Data,Var,Abs,NWrp,Lin,Pref,NNul,NVol,Bit) 91 02
    Report Count (5) 95 05
    Output (Cnst,Ary,Abs,NWrp,Lin,Pref,NNul,NVol,Bit) 91 01
End Collection C0

I'd ideally parse this information for all "Usage (Keyboard)" so I know what I'm receiving, even from the weirdest of keyboards.
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 589
    • View Profile

Hello,

The following function should help:

USBH_device_get_descriptor(hDev, USB_DESCRIPTOR_TYPE_REPORT, index, offset, buffer)

USB_DESCRIPTOR_TYPE_REPORT comes from ft900_usb_hid.h.

Best Regards,
FTDI Community
Logged