-
-
Notifications
You must be signed in to change notification settings - Fork 39.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor and Configurator updates for AMJ Pad #3060
Conversation
keyboards/amjpad/amjpad.h
Outdated
k30, k31, k32, k33, \ | ||
k40, k41, k42, k43, \ | ||
k50, k51, k52, k53\ | ||
#define LAYOUT_all( \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LAYOYUT_ortho_6x4
maybe? :)
keyboards/amjpad/amjpad.h
Outdated
k30, k31, k32, \ | ||
k40, k41, k42, k43, \ | ||
k50, k52 \ | ||
#define LAYOUT( \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a couple of 6 row keypads. Maybe we should have some layouts for them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had actually considered doing just that, but I wasn't sure 1) if it was wanted and a good idea, and 2) what changes it would require of my workflow, if any.
I was thinking of something like the following:
- LAYOUT_ortho_6x4
- LAYOUT_ortho_5x4
- LAYOUT_numpad_6x4
- LAYOUT_numpad_5x4
numpad
layouts would be 2u Num 0
with Num +
and Num Enter
both vertical.
The caveat I have about these is some numpads are wired where the vertical keys are on the 789
and 123
rows, and some are 456
and 0.
rows. So not sure if the numpad ones are a good idea because of that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good.
And for the odd boards, LAYOUT_numpad_offset or the like may be a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we decide which one is offset, though?
Also, did you want me to actually recommit LAYOUT_all
as LAYOUT_ortho_6x4
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, you mean the actual matrix placement?
In theory, that shouldn't matter, if the macro is set to handle that, Though, visually, ... that would matter, wouldn't it.
Visually, I think that 456/0 would be better visually, since it makes the space more obvious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Below is what I'm talking about:
Basically, either the style on the left or the one on the right becomes LAYOUT_numpad_5x4
, and the other is LAYOUT_numpad_5x4_offset
or something like that. Keymaps written for one don't work on the other (different number of keys per row), and how do we make this plain/obvious for other people contributing?
This also disregards the possibility someone makes a PCB/matrix where the 2u Num 0
key is col1 instead of col0. Or some hodgepodge of all the above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The key config is the same, right? Eg, the placement for users is the same.
In that case, it doesn't matter for the LAYOUT. That's the point. The reason we use the LAYOUT macro is so that we can remap the matrix.
So, both of these work on the same layout:
#define LAYOUT_numpad_5x4( \
k00, k01, k02, k03, \
k10, k11, k12, k13, \
k20, k21, k22, \
k30, k31, k32, k33, \
k40, k42 \
) \
{ \
{k00, k01, k02, k03}, \
{k10, k11, k12, k13}, \
{k20, k21, k22, XXX}, \
{k30, k31, k32, k33}, \
{k40, XXX, k42, XXX}, \
}
#define LAYOUT_numpad_5x4( \
k00, k01, k02, k03, \
k10, k11, k12, k23, \
k20, k21, k22, \
k30, k31, k32, k43, \
k40, k42 \
) \
{ \
{k00, k01, k02, k03}, \
{k10, k11, k12, XXX}, \
{k20, k21, k22, k23}, \
{k30, k31, k32, XXX}, \
{k40, XXX, k42, k43}, \
}
The matrix itself is different, but the LAYOUT/keymap is the same for both boards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though, this would look better:
#define LAYOUT_numpad_5x4( \
k00, k01, k02, k03, \
k10, k11, k12, \
k20, k21, k22, k13, \
k30, k31, k32, \
k40, k42, k33, \
) \
Looks great! |
* Refactor for AMJ Pad * Configurator update for AMJ Pad * Add hardware agnostic layouts numpad_6x4 and ortho_6x4 * Add agnostic layouts to rules.mk * Refactor AMJ Pad to use new hardware agnostic layouts
* master: (622 commits) Refactor and Configurator updates for B.mini (qmk#3081) qwerty_code_friendly: add numbers keys (qmk#3078) Switch to noeeprom variants of rgb fns (qmk#3077) Add bpruitt-goddard Ergodox Layout (qmk#3080) Add and fix _noeeprom functions to many of the RGB Underglow functions (qmk#3070) Keymap fixes (qmk#3074) Refactor and Configurator updates for Woodkeys/NovelKeys Big Series (qmk#3073) Kbd8x backlight support (qmk#3069) Refactor and Configurator updates for Bantam44 (qmk#3071) Configurator updates for Atreus/Atreus62 (qmk#3065) fix a few simple typos (qmk#3068) Update Canoe ps2avr board (qmk#3066) Indicator led support for KBD8X (qmk#3064) Fix nyquist (and other splits using D2 in debouncing) (qmk#3067) Add Canoe support (qmk#3063) Refactor and Configurator updates for AMJ Pad (qmk#3060) Refresh & improve leader documentation page (qmk#2990) Refactor and Configurator updates for AMJ60 (qmk#3055) Adding guidoism's planck layouts (qmk#3059) Add mtdjr keymaps for Iris, Let's Split, TADA68, XD75, and handwired dox (qmk#3058) ...
* Refactor for AMJ Pad * Configurator update for AMJ Pad * Add hardware agnostic layouts numpad_6x4 and ortho_6x4 * Add agnostic layouts to rules.mk * Refactor AMJ Pad to use new hardware agnostic layouts
No description provided.