X component in USB mouse report is always 0

I am new to the USB protocol, and I just finally have been able to upload the HOST USB HID example project for a ESP32S3 board. I want it to be able to communicate with a USB mouse. The example project seems to be fine with keyboards, but for a mouse, it only responds to horizontal movements. However, horizontal movements change the Y component of the report, perhaps this is a clue to the issue?

I have looked through Espressif's example code and I don't see any obvious errors. Here's an example of the terminal output X: 000000 Y: 003992 | | |. The mouse works fine when connected to a computer, so I think we can rule out any hardware issues.

If I modify the code so that I count all reports in one variable, and all reports where the Y component is 0 in another variable, and then move the mouse as straight as I can upward (the X direction I guess because the Y is left and right), If I do those things then I get a non-zero number of reports where the Y component is 0. In fact, I can get about 50% of reports where the Y component is 0;

I think that the mouse is sending the data, but the code is throwing out the data somewhere. Why else would the mouse report movement if there was no movement. If I don't move the mouse, then there are no reports, so its not just sending reports willy nilly. Also, if I move it in the Y, then there are almost no reports where the Y is 0. Perhaps this is a clue.

Does anyone have advice on how to get both x and y components of the mouse's movements?

Short answer: The important data was spaced out every other byte, so modify the code on line 314 to search for the 0th byte for the button clicks, 2nd byte for the x position, and 4th byte for the Y position
<s>

x_pos += mouse_report->x_displacement;<br>
y_pos += mouse_report->y_displacement;

</s>

x_pos += (int8_t)data[2];
y_pos += (int8_t)data[4];

Long answer: The Y data being left and right was a clue. The HID protocol says that the report comes in an array of 3 eight bit bytes and the first byte is the button presses, the second byte is the change in X and the third byte is the change in Y. The buttons were working on my mouse which is at the beginning of the array, and the "Y" was working at the "end" of the array. So it's not like the data is being sent incompletely like if it lobbed off the end, then it would have just been 2 bytes received.

(it is worth noting the "Y" would range from 0-20 if going right and 230-255 if going left. This makes sense since it is a signed 8 bit integer)

I wondered about if there was any other data lurking beyond the 3 bytes that were in the report. I read data[3] and got 0 if I was going right, and 255 if I was going left.
hmmm....strange behavior. What else is lurking in the shadows. I then read the next byte data[4] and got a value that changed when moving up and down. This is the true Y and data[2] is the true X.

I think this is probably due to a few things, perhaps all of my mice that I tried this out on were some sort of super fancy 16 bit mice or something that send 8 bits at a time in little endian mode. This would make sense because the other numbers would line up with 0xffFA for negative 5 and 0x0005 for positive 5 for example.

Also, I noticed one of the referenced libraries, the struct hid_mouse_input_report_boot_t has an attribute (packed). I'm not very familiar with that, but it looks like the compiler tries to really squish all the bytes together. So maybe some other part of the program doesn't pack it all up so close and thats why they mismatch or something. IDK.

I hope this goes on to help someone (or at least future me)