Repository navigation
feat: split: add asymmetric geometry support via split_mapping - #1136
Open
haricane8133 wants to merge 3 commits into
Open
haricane8133 wants to merge 3 commits into
haricane8133 wants to merge 3 commits into
Conversation
haricane8133
added a commit
to haricane8133/parrot90
that referenced
this pull request
Mar 22, 2026
…around This commit updates Parrot90 split firmware to use the newly introduced KMK asymmetric split mapping support via `split_mapping`. We have raised a PR to KMK here - KMKfw/kmk_firmware#1136 - Replaced manual/dummy asymmetric split handling with `split_mapping` in both halves. - Removed dependency on padded/dummy matrix assumptions for split compatibility. - Kept existing keymap indexing behavior by explicitly setting right-half base index. - Updated split config on both `code_L.py` and `code_R.py` to use: - `rows` - `left_cols` - `right_cols` - `right_start` - `split_flip` The previous approach required brittle matrix padding; large static mapping assumptions. This new config is explicit, easier, and directly models the physical keyboard geometry. - Left-half mapping verified. - Right-half mapping corrected and verified after right-side base alignment. - Firmware compiles successfully after changes.
Member
|
We do have a mechanism which allows for asymmetric splits. It may not be very intuitive but it also allows for empty matrix intersections, which your PR doesn't seem to. |
This change adds first-class asymmetric split support to KMK `Split`
using one new optional parameter: `split_mapping`.
Current split auto-mapping is symmetric-oriented and assumes equivalent geometry across halves.
Asymmetric keyboards require fragile workarounds (dummy matrix definitions or hand-crafted mappings).
Add `split_mapping` as a single, additive configuration input.
When provided, `Split` computes `keyboard.coord_mapping` internally from geometry.
`split_mapping` fields:
- `rows`
- `left_cols`
- `right_cols`
- `right_start` (optional, for custom logical indexing schemes)
- `split_flip` (optional)
- If `split_mapping` is present: use computed asymmetric mapping.
- If absent: preserve current auto-mapping behavior.
- Backward-compatible for existing users.
- No transport behavior changes.
- Existing split configs continue to work unchanged.
3) PR Description (KMK clean)
Adds asymmetric split mapping support to KMK `Split`
through a single optional parameter: `split_mapping`.
Split auto-mapping currently favors symmetric geometries.
Asymmetric builds often need fragile setup patterns (dummy definitions/manual mappings),
which increases user error and maintenance cost.
```python
split = Split(
split_type=SplitType.UART,
split_side=SplitSide.LEFT, # or RIGHT
split_target_left=True,
split_mapping={
"rows": 6,
"left_cols": 7,
"right_cols": 11,
"right_start": 66, # optional
"split_flip": False, # optional
},
data_pin=...,
data_pin2=...,
)
- Add split_mapping to Split.
- Add internal mapping generation for asymmetric geometry.
- During boot, if split_mapping exists, compute and set keyboard.coord_mapping.
- Keep existing auto-mapping path unchanged when split_mapping is not supplied.
- Additive API only.
- Existing split users are unaffected unless they opt in.
- Verified successful firmware compile.
- Verified asymmetric left/right mapping correctness in a real split setup.
Parrot90 integration example: https://github.com/haricane8133/parrot90
haricane8133
force-pushed
the
main
branch
2 times, most recently
from
September 13, 2026 13:01
c76c849 to
ddb3f4c
Compare
KMK already supports asymmetric splits via a hand-written keyboard.coord_mapping; a documented example is a better fit than a new Split parameter. This reverts commit e7cef4b7ce40c3fe1d92e3fd4bc5cc1fdbf5c7ee.
Author
|
@regicidalplutophage, yes you are right. I have reverted my commit and made just a docs change |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change adds first-class asymmetric split support to KMK
Splitusing one new optional parameter:split_mapping.Current split auto-mapping is symmetric-oriented and assumes equivalent geometry across halves. Asymmetric keyboards require fragile workarounds (dummy matrix definitions or hand-crafted mappings).
Add
split_mappingas a single, additive configuration input. When provided,Splitcomputeskeyboard.coord_mappinginternally from geometry.split_mappingfields:rowsleft_colsright_colsright_start(optional, for custom logical indexing schemes)split_flip(optional)If
split_mappingis present: use computed asymmetric mapping.If absent: preserve current auto-mapping behavior.
Backward-compatible for existing users.
No transport behavior changes.
Existing split configs continue to work unchanged.
Adds asymmetric split mapping support to KMK
Splitthrough a single optional parameter:split_mapping.Split auto-mapping currently favors symmetric geometries. Asymmetric builds often need fragile setup patterns (dummy definitions/manual mappings), which increases user error and maintenance cost.