Improvements to extrakey HID descriptors

[fauxpark]

Description

As mentioned in #963, these descriptors are declared as Array, so the logical value sent over the wire is the 1-based index of the usage between Usage Minimum and Usage Maximum. Only one value can be asserted at a time, and a value of 0 means nothing pressed.

I've reverted the range of the System usages from just the three power keycodes to the entire thing so that one can send arbitrary usages with host_system_send(). Now we don't need to do the whole data - SYSTEM_POWER_DOWN + 1 first, as usage 1 == index 1.

Similarly I increased the range of the Consumer usages slightly, to allow for some of the newer additions to the page such as the macOS Launchpad and Mission Control usages (#4762). They still don't have their own keycodes yet, but you can now at least DIY.

I couldn't reproduce the issue with macOS seeing QMK as a mouse/tablet (#510) on Catalina... except for with V-USB, until I realised that the extrakey descriptor is part of the mousekey descriptor's array, and the latter is always present even if MOUSE_ENABLE is not defined. So I chucked a bunch of ifdefs in vusb.c to handle the cases of either extrakeys or mouse being disabled, and both at the same time. Should save some bytes!

Tested and working on LUFA, ChibiOS and V-USB. Again, I can't test ATSAM, but the changes to the descriptors are much the same as the other stacks, and the CTRL and ALT both compile 😄

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[tzarc]

Confirming that extrakey functionality still working on a CTRL with this patch.

[tzarc]

I've reverted the range of the System usages from just the three power keycodes to the entire thing so that one can send arbitrary usages with host_system_send(). Now we don't need to do the whole data - SYSTEM_POWER_DOWN + 1 first, as usage 1 == index 1.

I'm not massively familiar w ith the HID usage tables, so I'm not sure if the following is an issue (or if I'm reading it correctly).

The power buttons (0x81-0x83) are all "on/off control" usage type, which I'd imagine matches a normal keypress in the eyes of the system... and can be represented by on/off bitmask.
Other parts of the desktop page have different usage types, including dynamic values (0x30-0x39, etc) -- is it appropriate that they're on/off bits in the array?

Should we really be extending the range outside the "button press" section?

EDIT: I'm now not even sure my interpretation is correct, anyway.
If it's a bitmask, and if we're now allowing for 0x01->0xB7, then16 bytes won't be enough for 0/1 for each of the IDs.
If it's "usage ID + payload of 16 bytes" then sure, but I don't see it.

[fauxpark]

It's not a bitmask, it's an array index. From the HID Device Class Definition, section 6.2.2.5:

An array provides an alternate means for describing the data returned from a group of buttons. [...] Rather than returning a single bit for each button in the group, an array returns an index in each field that corresponds to the pressed button (like keyboard scan codes). An out-of range value in and array field is considered no controls asserted.

For example, currently the usage min/max of the System descriptor is 0x81-0x83, and the logical min/max is 0x01-0x03. So to assert the 0x81 (System Power Down) usage, you send 0x01, and so on. This is why SYSTEM_POWER_DOWN + 1 had to be subtracted from data before actually sending it. Now that the usage min/max is the same as logical, we don't need to do that anymore.

As for extending the range outside of the button press "section" - there is no such thing really, the usage types are all over the place. The Consumer descriptor does the same thing. Sure, some of the declared usages don't make total sense wrt their types but it's whatever. I don't think you can declare multiple non-contiguous ranges for the same field anyway.

[tzarc]

Confirmed that this fixes #6203 by users "Daniel Goodman" and "colon-d" on discord with their dz65's.