Update 1:ESP32-S3 - TinyUSB - mouse: scroll wheel does not work when mouse is connected to ESP32-S3,but works if to a PC

[sraposo]

ESP32-S3 - TinyUSB

I've just faced a weird situation: an USB Logitech mouse, that fully works when connected to a PC, does not send any byte related to scroll wheel. Input report contains only 3 bytes: 1 for buttons (including the scroll wheel switch), other for horizontal movement and the last for vertical direction. None of them present any variation when scroll wheel is spun.

Another mouse, brand Knup, has a 4-byte input report, where the 4th byte is dedicated to the scroll wheel movement.

With this 3-byte report from Logitech mouse, it is not possible to get any indication about scroll wheel action, so I SUPPOSE there's something wrong/different in this connection between Logitech mouse and ESP32-S3/TinyUSB, but I have no clue!

Some reading of USB specification and checking TinyUSB files gave me no idea how to cope with this.

**************************************************************************************************************************
UPDATE 1:
**************************************************************************************************************************
When Logitech mouse is connected, in the struct "hid_iface_t", field "in_xfer" (type usb_transfer_t), the following sub-fields contains:
* data_buffer_size (type const size_t) = 4
* num_bytes (type int) = 4
* actual_num_bytes (type int) = 3

With Knup mouse, the field "actual_num_bytes" contains value 4. This forth byte is the one that stores the scroll wheel data.

Why USB stack fulfils only 3 bytes of the "data_buffer" when Logitech mouse is on?



Can anybody point me some direction?

[Manoel]

Hello, were you able to solve your problem? I'm facing something similar: on some mice, the HID data doesn't contain the wheel information. Regarding the 3 bytes you mentioned, I noticed through a sniffer with Wireshark that these mice (where the wheel doesn't work) send some kind of "ID" in the first byte. I'm still dealing with this issue.

[sraposo]

Hi, Manuel.

No progress yet. I've also checked by WireShark that there are USB events when scroll wheel is moved, but I could not get any useful clue.

I've been spending a LOT of time trying to find where this information resides but I was not successful. I could not find any special event, non-obvious byte hidden in some structure...

It's a no-man land. Each mouse maker sends HID device information the way they want to, since paired with a proprietary device driver.

If any news, I'll post here.

Good luck for us!

[chegewara]

There is a lot to say in that topic, but i will try to keep it short:
- this is not tinyUSB library; tinyUSB is for device, but you are using USB host
- that some kind of ID in first byte is report ID
- more than USB knowledge you need to do extensive research about HID protocol; there is no proprietary data, it is all about HID specification which is based on HID reports (which should be correctly parsed before yu can use data from device)

[Manoel]

I truly understand that the issue is not with the protocol but rather with the communication the ESP is having with the mouse. The way the native "hid host" library is configured, only 3 bytes arrive in the output. For some older mice, I was able to make it work perfectly. However, with newer mice, it seems that the scroll bytes come after these three bytes. It works like this: buttons -> (byte 1), X movement -> (byte 2), and Y movement -> (byte 3). I tried in every possible way to change the number of bytes received but without success. I found a line called "USB_SETUP_PACKET_SIZE" in a file named "usb_types_ch9.h," which was defined as 8, but even after modifying it, I had no success. There is a file called "USB_TYPES_STACK.H," where the USB transmission speed and type of transmission are selected (which apparently influences the packet size), but the program as a whole does not work at other speeds.

[sraposo]

Maybe I have not studied enough the HID specification to find it... but it's pretty curious that some brands/models group four bytes related to mouse controls and coordinates while other don't include scroll wheel info in a 3-byte pack...

Well, I'll check HID specification again.
https://www.usb.org/documents

Regards

[sraposo]

I truly understand that the issue is not with the protocol but rather with the communication the ESP is having with the mouse. The way the native "hid host" library is configured, only 3 bytes arrive in the output. For some older mice, I was able to make it work perfectly. However, with newer mice, it seems that the scroll bytes come after these three bytes. It works like this: buttons -> (byte 1), X movement -> (byte 2), and Y movement -> (byte 3). I tried in every possible way to change the number of bytes received but without success. I found a line called "USB_SETUP_PACKET_SIZE" in a file named "usb_types_ch9.h," which was defined as 8, but even after modifying it, I had no success. There is a file called "USB_TYPES_STACK.H," where the USB transmission speed and type of transmission are selected (which apparently influences the packet size), but the program as a whole does not work at other speeds.

I have also tried to change these fields. Indeed, I have tried to seek in several data structures a byte that changed value according scroll wheel movement and I had no success. Also experimented other report IDs.

[Manoel]

I discovered something from a report generated by the USB Device Tree software. Apparently, the mice (even those that don't work) are indeed operating (in Windows) in USB 1.1 mode and at LOW speed. The only difference is the type of packet transmission, which in Windows is set to "Interrupt." However, when selecting this mode on the ESP32, the program as a whole stops working.

[sraposo]

Callback function associated to hid_host_device_open never generated some special event related to the scroll wheel for those mice that returns a 3-byte pack via hid_host_device_get_raw_input_report_data.

I have ever considered if device driver for those mice send some special report (like ESP_IDF's hid_class_request_set_report) in order to set mice to another state that would make them provide scroll wheel info... just guessing...

[chegewara]

All you are talking about is still USB specification related and has nothing to do with HID report and data structure which mouse is sending.
Espressif usb hid mouse driver is very simple one (just guessing, never tested it) and probably wont wont with mice when cursor data and wheel data are sent with different report ID, not as one data.
This is example of HID report

Code: Select all

    0x05, 0x01,    // UsagePage(Generic Desktop[1])
    0x09, 0x04,    // UsageId(Joystick[4])
    0xA1, 0x01,    // Collection(Application)
    0x85, 0x01,    //     ReportId(1)
    0x09, 0x01,    //     UsageId(Pointer[1])
    0xA1, 0x00,    //     Collection(Physical)
    0x09, 0x30,    //         UsageId(X[48])
    0x09, 0x31,    //         UsageId(Y[49])
    0x15, 0x80,    //         LogicalMinimum(-128)
    0x25, 0x7F,    //         LogicalMaximum(127)
    0x95, 0x02,    //         ReportCount(2)
    0x75, 0x08,    //         ReportSize(8)
    0x81, 0x02,    //         Input(Data, Variable, Absolute, NoWrap, Linear, PreferredState, NoNullPosition, BitField)
    0x05, 0x09,    //         UsagePage(Button[9])
    0x19, 0x01,    //         UsageIdMin(Button 1[1])
    0x29, 0x03,    //         UsageIdMax(Button 3[3])
    0x15, 0x00,    //         LogicalMinimum(0)
    0x25, 0x01,    //         LogicalMaximum(1)
    0x95, 0x03,    //         ReportCount(3)
    0x75, 0x01,    //         ReportSize(1)
    0x81, 0x02,    //         Input(Data, Variable, Absolute, NoWrap, Linear, PreferredState, NoNullPosition, BitField)
    0xC0,          //     EndCollection()
    0x05, 0x02,    //     UsagePage(Simulation Controls[2])
    0x09, 0xBB,    //     UsageId(Throttle[187])
    0x15, 0x80,    //     LogicalMinimum(-128)
    0x25, 0x7F,    //     LogicalMaximum(127)
    0x95, 0x01,    //     ReportCount(1)
    0x75, 0x08,    //     ReportSize(8)
    0x81, 0x02,    //     Input(Data, Variable, Absolute, NoWrap, Linear, PreferredState, NoNullPosition, BitField)
    0x75, 0x05,    //     ReportSize(5)
    0x81, 0x03,    //     Input(Constant, Variable, Absolute, NoWrap, Linear, PreferredState, NoNullPosition, BitField)
    0xC0,          // EndCollection()
    

Its for joystick, but it is to show you what i mean.