Do all USB mouse have a report with same structure?

[matrixofdynamism]

USB report contains information about button presses and changes in x and y axis since last report. This data can be arranged in any order.
Do USB mouse follow the same report stucture as in the button presses are in lower bits of byte 0 followed for usage x byte and usage y byte for example? I do not have many USB mice to test myself.

If this is the case then that means that a USB embedded host does not need to read in the report descriptor and parse it, as long as it sets the configuration of the USB mouse, one can just start reading data from it via interrupt transfers.

The whole idea of parsing a report descriptor appears like a complex task. Windows does seem to have its own functions to do this however, I guess that in an embedded host, one shall have to do it manually. This means that most likely one may have to have an OS on the embedded host that has USB stack.

[Jan Axelson]

The HID specification defines a boot mouse protocol and provides a report descriptor for it.

Mice are not required to support the boot protocol (bInterfaceSubClass = 1), however.

For the non-boot protocol, the HID specification doesn't provide a required report descriptor. 

[matrixofdynamism]

I see, this means that if even if I know how many bytes are in the report, I will still need a way to prase the report descriptor. Alright then.

[Jan Axelson]

Yes, that is the purpose of the report descriptor.

[matrixofdynamism]

I have found the boot protocol information to be rather interesting as it exists in the device Interface Descriptor itself and tells if the interface supports USB Mouse or USB Keyboard protocol. Neat.

By the way, while the report descriptor very elaborately describes in a neat hierarchical structure, the number and contents of reports for each interface, is there a "short hand" way to find out how many bytes there are in a report returned in an interrupt IN transfer? It seems to me that parsing the report is the only way to find out how many bytes must be transferred in an IN (or even OUT for that matter) transfer.

There seems to be no field in the HID or report descriptor like bReportSize, the wDescriptorLength in the HID descriptor gives length of the report descriptor rather than the report itself.

[Jan Axelson]

For HIDs that use only the default report ID of zero, the host knows the report length, and thus the transfer length, from the report descriptor.

When a HID uses multiple report IDs, the transfer begins with the report ID so the host will know the expected report length from that as well.

A short packet (which may be a zero-length data packet) indicates end of transfer when needed. From the HID spec, 8.4:

All reports except the longest which exceed wMaxPacketSize for the endpoint
must terminate with a short packet. The longest report does not require a short
packet terminator.

If there are multiple reports in a top level collection then all reports, except the
longest, must terminate with a short packet.