Is there a bug in the HAL USB HID mouse code?

[AWolf.8]

The type definitions for HID_MOUSE_Info_TypeDef in the latest usbh_hid_mouse.h file in the STM32L4 package defines the x and y fields as uint8_t. The STM32Cube USB host library documentation says they should be int8_t. The USB specification seems to conform to the manual, not the code. This makes sense - the mouse should move in positive and negative directions.

Is this a known bug? What is the protocol for fixing bugs like this in libraries?

[hashtala]

I had same thing going on. buffers were 8 bit unsigned integers. However, when I wrote values between 128-256 it would go into the negative direction.

Thing was that this value was interpreted as an two's complement - int8. while 128 was most negative and 256 least negative (-128, -1).

Maybe same thing is going on there, and x and y values are jut placeholders. be sure to play with numbers to make better sense out of it

[AWolf.8]

After more analysis, this is definitely a library bug. As you noted - no bits are lost so it is possible to write a conversion routine to extract the correct value - but a simple cast or performing a <0 test or allowing the value to be promoted to an integer gives the wrong value.

[hashtala]

I suggest you to just use custom HID report. Solves problem. In cubeMX you have to choose Custom HID though.