fix(os_detection): don't classify macOS sequences as Windows
macOS 26.x (ChibiOS) can send a late wLength=0x04 packet after the two
0xFF packets that already established OS_MACOS. The Windows check
(cnt_ff >= 2 && cnt_04 >= 1) fired on this combination and overwrites
the correct result.
Real-world Windows sequences always start with 0xFF packets (cnt_02 = 0);
macOS sequences always open with at least two 0x02 packets (cnt_02 >= 2).
Adding && setups_data.cnt_02 < 2 to the Windows condition is sufficient
to separate the two populations without affecting any existing detection.
Adds a regression test for the affected sequence.
* usb_device_state: add idle_rate, led and protocol
Previously all usb drivers and platform implementations (expect for our
oddball atsam) tracked the same two global variables:
- keyboard_protocol: to indicate if we are in report or boot protocol
- keyboard_idle: for the idle_rate of the keyboard endpoint
And a local variable that was exposed trough some indirection:
- keyboard_led_state: for the currently set indicator leds (caps lock etc.)
These have all been moved into the usb_device_state struct wich is
accessible by getters and setters.
This reduces code duplication and centralizes the state management
across platforms and drivers.
Signed-off-by: Stefan Kerkmann <karlk90@pm.me>
* usb_device_state: reset protocol on reset
The usb hid specification section 7.2.6 states:
When initialized, all devices default to report protocol. However the
host should not make any assumptions about the device’s state and should
set the desired protocol whenever initializing a device.
Thus on reset we should always do exactly that.
Signed-off-by: Stefan Kerkmann <karlk90@pm.me>
* keyboards: fix oversize warnings
Signed-off-by: Stefan Kerkmann <karlk90@pm.me>
---------
Signed-off-by: Stefan Kerkmann <karlk90@pm.me>
Jens van Almsick