usb_hid: Fix MaxReportSize computation

While calculating buffer size for IN reports, only "Input" report type
should been taken in account. Complex HID devices, such as "Gaming"
keyboards and mice, often have "Feature"-reports declared (with size way
bigger than "typical" kbd IN report) for vendor-specific device
configurations.

But "Feature"-reports are sent over control channel only and can't
appear on interrupt channel.

Should fix #14919, #17937, #17699

Change-Id: I4b9eb51938ca4aba2bc34247d00ae164eb2c19fc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5771
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

Remove trailing whitespace from hid_shared

Introduced in https://review.haiku-os.org/c/haiku/+/4403

366e9a62e9ee4446bfd2017320c20dd0796d9a1a => hrev55413

This is a whitespace only change, no functional changes.

hid: Fixed report parsing bug. Support for keyboards using bitmap reports

* I've added support to multiple min-max ranges to array reports too.
* All possible usages are stored in an array (Vector<uint32>). Perhaps, this can be squashed into an array of ranges.
* Usage array is stored in HIDReport class, so there is only one copy of it.
* HIDReportItem no longer has UsageMinimum()/UsageMaximum() as this no longer works. Instead, a Usage() member has been introduces.
* HIDReportItems of type variable, have a Usage ID assigned to them. HIDReportItems of type array have a zero usage ID as it has no sense.
* Having a variable typed HIDReportItem to store a range of usages ID doesn't seem a good idea to me because Data() method would have to return the values of all usages... or perhaps ask for a specific usage value with something like Data(0x03). This will require changes in hid stack and overcomplicate things.
* A bitmap keyboard is a worst-case scenario: Near a hundred of usages (uint32) are stored and the same quantity of HIDReportItems are created (this is already happening on Haiku). It doesn't seem a resource drama to me.
* Keyboard Handler has room for improvement, but I would like to left that for another patch series.

Change-Id: I556fa0aebfda831ef5334be5ae3a37f099ffa35d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4403
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

Updated HID code with Vector class instead of hand made growing arrays

Change-Id: Iec8cd3922d9c21a046d225181d326253ae88d395
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4324
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

i2c_hid: driver for i2c-hid devices

This is getting more common in tablets and laptops. It replaces PS/2 for
the internal keyboard and pointing devices. This is simpler and cheaper
than using up USB ports, and also simpler than the old and quirky PS/2
protocol.

The HID spec is the same no matter what transport is used (it is also
applicable for Bluetooth). Ideally we could create a separate HID bus
manager that would handle all these devices in a generic way, but that
is a lot of work nad extra complications for uncertain gains.

For now, just move the common files to a shared directory where both
drivers can use them. As a result the files are compiled twice, which is
what we want, because currently they hardcode some device paths that
need to be different for each driver.

Change-Id: I0327f6864dd0a4372b708f7b7ecf299aa86a6ea9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2466
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>