Problem:
`mousekey_task` spams empty hid reports with when a mouse key is
pressed, causing resource exhaustion in the USB mouse endpoint.
Cause:
The check whether or not to send a new mouse report would always
evaluate to true if a mouse key is pressed:
1. `mouse_report` has non-zero fields and `tmpmr` is a copy of this
fields.
2. `mouse_report` is set to zero, `tmpmr` has now non-zero fields.
3. `has_mouse_report_changed` compares the two and evaluates to true
4. a mouse report is sent.
Fix:
The check condition of `has_mouse_report_changed` will evaluate any
empty record as unchanged, as mouse report data is relative and doesn't
need to return to zero. An empty report will still be send by
`register_mouse` on release of all mouse buttons.
Keychron Q11 uses `matrix_mask` to mask away the matrix location used
for `SPLIT_HAND_MATRIX_GRID` (otherwise the keyboard will constantly
generate a wakeup request whenever the host enters suspend). However,
the value of `matrix_mask` is actually chosen to mask away all unused
locations, but it was apparently generated for the ANSI board and
therefore masks away the left Shift key on the ISO board, breaking the
functionality of that key.
Fix `matrix_mask` to make the masking work as intended:
- Set the `[4, 1]` bit to 1; this is the matrix location for the ISO
left Shift.
- Set the `[2, 5]` bit to 0; this is actually the matrix location which
corresponds to `#define SPLIT_HAND_MATRIX_GRID A2, A15` on the left
side, which was intended to be masked; apparently the wakeup problem
does not happen due to `SPLIT_HAND_MATRIX_GRID_LOW_IS_RIGHT`, so the
left half actually has that matrix location open. On the right side
`A2, A15` is `[9, 6]`, which was masked off correctly.
Running the "HID Tests" suite of the USB 3 Command Verifier (USB3CV)
tool resulted in the following error:
(HID: 3.2.61) The report descriptor returned in response to a
GetDescriptor(Report) must be compliant with the HID specification.
Byte Number: 37h ( 55d)
Data Field: 91 02
Mnemonic: Output
Value: (Variable)
Errors: Error: LOGICAL MAX MUST be bounded by Report Size
The error stems from the fact that logical minimum and maximum are
global items, which means that the next item in a report descriptor
inherits the value from the previously set value. In this case the
status leds item inherited the logical minimum (=0) and maximum (=255)
from the keycodes item. As the status leds set a report size of 1 bit,
wich can only hold a boolean, it becomes clear that this range would
never fit.
The fix is straightforward, we just define a appropriate logical maximum
(=1), the mismatch is solved and our keyboard now passes the compliance
tests. Defining the logical minimum is redundant in this case but is
kept to form a logical block.
The code for Helix rev3 boards could not be built with, e.g.,
`CONVERT_TO=rp2040_ce` due to invalid `#include <stdio.h>` in the
keyboard level `config.h` (apparently the AVR version of that file
contains guards against usage in assembly code, which was hiding the
bug). Move `#include <stdio.h>` to the C sources which need it.
Co-authored-by: adophoxia <100170946+adophoxia@users.noreply.github.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: wb-joy <chang.li@westberrytech.com>
Co-authored-by: Joy Lee <joylee.lc@foxmail.com>
