Skip to main content
AWolf.8
AWolf.8
Associate II
May 9, 2020
Question

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

  • May 9, 2020
  • 3 replies
  • 846 views

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?

This topic has been closed for replies.

3 replies

hashtala
hashtala
Associate III
May 9, 2020

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
AWolf.8Author
Associate II
May 9, 2020

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
hashtala
Associate III
May 9, 2020

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

Terms & ConditionsAccessibility statement