* [style] refactor keymaps
- use four-space indent
- grid-align keycodes
- use QMK-native keycode aliases
* [style] friendly-format info.json
* [chore] remove key overlaps in layout data
* [chore] correct key sequence
* [chore] add key labels
Add `label` keys to the JSON layout data to disambiguate which keys each
object is meant to represent.
Based on the original key sizes and positions as submitted by the
maintainer.
* [docs] add layout/matrix diagram
* [refactor] rename LAYOUT to LAYOUT_all
* [enhancement] add LAYOUT_tkl_ansi_split_bs_rshift
* [enhancement] add LAYOUT_tkl_iso_split_bs_rshift
* [enhancement] enable Community Layout support
* [style] friendly-format info.json
- sort JSON keys in layouts object
- remove instances of `w: 1`
* [chore] correct layout data
* [refactor] rename LAYOUT to LAYOUT_60_tsangan_hhkb
* [enhancement] add LAYOUT_60_ansi_tsangan_split_rshift
* [enhancement] enable Community Layout support
* [bugfix] write appropropriate keymaps
Neither the `default` nor `via` keymaps were written appropriately for
this keyboard.
This commit modifies both keymaps to be appropriate for
`60_tsangan_hhkb` layout.
* Update ChibiOS-Contrib for USB suspend fixes
* Remove S3 wakup workaround
ChibiOS OTGv1 driver has a remote wakeup bug that prevents the device to
resume it's operation. 02516cbc24647f522eee975e69cc0c8a925470eb
introduced a hotfix that forcefully restarted the usb driver as a workaround.
This workaround broke multiple boards which do not use this driver /
peripheral. With the update of ChibiOS this hotfix is now obsolete.
* Remove restart_usb_driver overrides
they are no longer necessary as the workaround is not needed anymore
for stm32f4
* Remove unused RP_USB_USE_SOF_INTR defines
The SOF interrupt is enabled dynamically by the RP2040 usb driver
According to the USB 2.0 spec, remote wakeup should be disabled by
default, and should only be enabled if the host explicitly requests
it. The chibios driver code already takes care of storing this
information, and returning it on GET_STATUS requests. However our
application code has been ignoring it so far.
This is a USB compliance issue, but also a bug that causes trouble
in some cases: On RP2040 targets this has been causing problems if
a key is held down while the keyboard is plugged in. The keyboard
would fail to enumerate until all keys are released. With this
change that behavior is fixed.
Note that for LUFA targets this is already done correctly.
