[Feature Request] USB feature report handling

Feature Request Type

• Core functionality
• Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
• Alteration (enhancement/optimization) of existing feature(s)
• New behavior

Description

I have been doing some work to support trackpads within the digitizer feature. To do this I have had to implement support for a few Get/Set Feature reports. In particular:

Microsoft require 2 Get Report features:

• A device capabilities report (https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection#device-certification-status-feature-report)
• A device certification report (https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection#device-certification-status-feature-report)

The certification report is a pain as its 257 bytes, but Windows 8.1 wont work without a valid response. Later versions of Windows require us to return something, but they don't validate it.

We also need to support the following Set Report features:

• Input mode - we are supposed to report as if we are a mouse until the host sends us this message (https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-configuration-collection?source=recommendations#input-mode-feature-report)
• Selective mode reporting - we should disable the trackpad/buttons on demand (https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-configuration-collection?source=recommendations#selective-reporting-feature-report)

I currently have some hacked together report handling code which works, but I would like to make it nicer. I have seen that @KarlK90 has just redesigned all the report handling code, and I was wondering how I can best take advantage of it. The Get Report values are known at compile time, so I was wondering about populating them in the report storage structure as complete reports at compile time, but the buffer (64 bytes) isn't big enough for the certification report. The set report handling doesn't appear to be in place, but perhaps the code could be extended a little?

It may also be nice if the actual content of these descriptors is platform independent, although the certification report will never fit on an AVR, we could at least support multitouch on Linux and fall back to mouse reporting on Mac (Apple do not support 3rd party trackpads) and Windows.

This functionality would also be useful for supporting high resolution scrolling in the pointing device feature.