* Don't print error message when there are no row pins and no col pins
This error message could be triggered for example if MATRIX_IO_DELAY is
configured in config.h, but the matrix is a custom one. The custom matrix
can still call back to existing delay functions that make use of the
MATRIX_IO_DELAY macro. In this case 'matrix_pins' in info_data will be true,
but there will be no 'direct' 'cols' or 'rows' in info_data['matrix_pins'],
and without this commit it would trigger an invalid error.
* Update lib/python/qmk/info.py
Co-authored-by: Nick Brassel <nick@tzarc.org>
---------
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
This contains commit from da78eb3759b8..9d7a7f904ed1:
9d7a7f90 Merge pull request #382 from KarlK90/fix/rp2040-i2c-speeds
70119934 Merge pull request #383 from
KarlK90/fix/rp2040-usb-get-status-request
1a1bbe6c rp2040: usb: fix usb_lld_get_status functions
7d9212dd rp2040: i2c: fix speed calculation
fb67e502 Merge pull request #377 from 1Conan/sn32_fix_registry
e72939ef SN32: update registry
5b4836ca Merge pull request #376 from dexter93/sn32_usb_v2
5ded9de9 sn32: usb: do NOT clear interrupt status until handled
Leftover Sonix reference code cleanup. Sometimes when there is
traffic on more than 1 ep's packets would be dropped before they
could be handled. Clearing the status flags after handling them
takes care of it.
e9a4a512 sn32: usb: only activate interrupts on lld start
e4a35d1c sn32: fix host remote wakeup
There was an import cycle in the Python modules:
- `qmk.build_targets` imported `qmk.cli.generate.compilation_database`;
- importing `qmk.cli.generate.compilation_database` requires
initializing `qmk.cli` first;
- the initialization of `qmk.cli` imported the modules for all CLI
commands;
- `qmk.cli.compile` imported `qmk.build_targets`.
This cycle did not matter in most cases, because `qmk.cli` was imported
first, and in that case importing `qmk.cli.generate.compilation_database`
did not trigger the initialization of `qmk.cli` again. However, there was
one corner case when `qmk.bulld_targets` was getting imported first:
- The `qmk find` command uses the `multiprocessing` module.
- The `multiprocessing` module uses the `spawn` start method on macOS
and Windows.
- When the `spawn` method is used, the child processes initialize
without any Python modules loaded, and the required modules are loaded
on demand by the `pickle` module when receiving the serialized objects
from the main process.
The result was that the `qmk find` command did not work properly on macOS
(and probably Windows too); it reported exceptions like this:
ImportError: cannot import name 'KeyboardKeymapBuildTarget' from partially initialized module 'qmk.build_targets' (most likely due to a circular import)
Moving the offending `qmk.cli.generate.compilation_database` import into
the method which actually uses it fixes the problem.
When multiple `-f FILTER` options were specified, `qmk find` did not
return anything at all instead of printing the list of entries that
matched all of the specified filters.
The problem was that the statement in `_filter_keymap_targets()` that
filled `targets` had a wrong indent and therefore was executed for every
filter instead of only once after applying all filters, and
`valid_keymaps` was actually an iterator and therefore could be used
only once. Moving the statement outside of the loop fixes the problem.
* 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. 02516cbc24
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
Functions in filters did not work properly except when used in the last
(or only) filter. The problem was caused by the peculiarity of the
`lambda` behavior in Python — any variables from the outer scope are
captured only by reference, therefore any subsequent reassignment of
those variables is propagated to all lambdas created earlier in the same
scope. Together with the laziness of `filter()` (it returns an iterator
which performs filtering on demand) this resulted in all function
filters using the values of the `key` and `value` variables which
correspond to the last filter in the sequence, therefore the result of
filtering was wrong if some filter with a function was not the last one
in the sequence.
Apparently the shortest way to make a Python lambda capture some
variables by value is to add arguments with default values for such
variables (default values are evaluated when the lambda is created, and
any subsequent reassignments in the outer scope no longer changes them).
This makes filters with functions work properly even when such filters
are not at the last position in the sequence.
