host/bare_api example - question/issue?

[Franticware]

Hi, I have built a host/bare_api example for RP2040 and the output is:

Device attached, address = 1

Device 1: ID 046d:c03e

Device Descriptor:

  bLength             18

  bDescriptorType     1

  bcdUSB              0200

  bDeviceClass        0

  bDeviceSubClass     0

  bDeviceProtocol     0

  bMaxPacketSize0     8

  idVendor            0x046d

  idProduct           0xc03e

  bcdDevice           2000

  iManufacturer       1     Logitech

  iProduct            2     USB-PS/2 Optical Mouse

  iSerialNumber       0     

  bNumConfigurations  1

Listen to [dev 1: ep 81]

[dev 1: ep 81] HID Report:

  00 FF 00 00 00 FF 00 00 00 FE 01 00 00 FE 00 00 

  00 FE 01 00 00 FE 00 00 00 FE 00 00 00 FF 01 00 

  00 FF 00 00 00 FF 00 00 00 FF 01 00 00 FE 01 00 

  00 FE 00 00 00 FD 00 00 00 FE 00 00 00 FE 01 00 

[dev 1: ep 81] HID Report:

  00 FE 00 00 00 FA 01 00 00 FE 01 00 00 FF 00 00 

  00 FF 00 00 00 FF 01 00 00 FF 00 00 00 FF 01 00 

  00 FF 00 00 00 FE 01 00 00 FF 01 00 00 FE 01 00 

  00 FE 01 00 00 FE 01 00 00 FD 02 00 00 FF 00 00 

[dev 1: ep 81] HID Report:

  00 FD 02 00 00 FC 04 00 00 FF 01 00 00 FF 01 00 

  00 FF 01 00 00 FF 01 00 00 00 01 00 00 FF 01 00 

  00 FD FF 00 00 FC FE 00 00 F7 FD 00 00 F5 FC 00 

  00 F1 F9 00 00 F2 FC 00 00 F0 FE 00 00 F5 FE 00 

The HID report callback outputs 64 bytes, but the report actually is just 4 bytes long, so the 64 bytes are 16 reports bunched together. It seems like the callback is called only when the 64 byte buffer is full. Is it supposed to work like that, or is it a bug?

I have tested 6 other mice and the situation was the same or worse where they did not even connect.

Only one - Acer SM-9625 - seemed to work as expected:

Device attached, address = 1

Device 1: ID 04ca:0030

Device Descriptor:

  bLength             18

  bDescriptorType     1

  bcdUSB              0110

  bDeviceClass        0

  bDeviceSubClass     0

  bDeviceProtocol     0

  bMaxPacketSize0     8

  idVendor            0x04ca

  idProduct           0x0030

  bcdDevice           0112

  iManufacturer       1     Lite-On Technology Corp.

  iProduct            2     USB Mouse

  iSerialNumber       0     

  bNumConfigurations  1

Listen to [dev 1: ep 81]

[dev 1: ep 81] HID Report:

  00 00 00 00 

[dev 1: ep 81] HID Report:

  00 00 00 00 

[dev 1: ep 81] HID Report:

  00 01 01 00 

[dev 1: ep 81] HID Report:

  00 FF FF 00 

[dev 1: ep 81] HID Report:

  00 02 00 00 

[dev 1: ep 81] HID Report:

  00 FF 00 00 

[dev 1: ep 81] HID Report:

  00 FF 01 00 

[hathach]

do you know how many bytes host (you code) requests, and how many bytes the device actually sent via the bus ? They may just leak/oversend 64b ytes if host request so, only 4 bytes is data, the rest could be garbage.

[Franticware]

All the 4-byte groups make sense in the 64-byte "report" and also, the frequency in which the report is received is about 16 times lower. This leads me to believe that all the data received is valid, but the reports are bunched or concatenated together. Not garbage.

Anyway, is the host/bare_api example supposed to receive HID_PROTOCOL_REPORT, or HID_PROTOCOL_BOOT? Because if the latter, then there might be an issue similar to that with other host HID examples, i.e. receiving incorrect data (see raspberrypi/pico-examples#489 for details).

Is it possible that HID_PROTOCOL_BOOT is not universally supported by all HID devices? That would explain a lot.

Setting tuh_hid_set_default_protocol(HID_PROTOCOL_REPORT) helped in case of host_hid_to_device_cdc, host_cdc_msc_hid, but here it gives linker error. Is there a different function for bare API?