gBoards GergoPlex #8928
gBoards GergoPlex #8928
Conversation
Co-Authored-By: Drashna Jaelre <[email protected]>
zvecr
added
keyboard
and removed
awaiting_pr
Co-authored-by: Drashna Jaelre <[email protected]>
|
Single line change to GergoPlex dicts, forgot that the eng-words dict was left enabled. |
|
@pirj Make sure your master branch is updated, the gboards folder was merged in a little while ago. This branch itself depends on those being avalible |
|
Good point, I was confused that I have to use this tree https://github.com/germ/qmk_firmware/tree/gboards-gergoplex, and was not aware of this pull request. Good to know gBoards are going mainstream in QMK. So, to help you reproduce (using I've edited What am I doing wrong? |
|
There's one thing that confused me, if you run while on this branch:
in either |
|
Ok, the culprit seems to be that this branch is not up to date with Also notice the
#define COMBO_COUNT 16
#define COMBO_ALLOW_ACTION_KEYS
+ #ifdef COMBO_TERM
+ #undef COMBO_TERM
+ #endif COMBO_TERM
#define COMBO_TERM 50 |
|
I'll get that updated tonight! Thanks for doing a dig on this, these PRs have been hanging around for a hot minute :( |
|
Sorry @drashna didn't realize that was holding this up. Formatted lol |
|
Dear QMK higher powers, |
|
I can lend a hand as well with this. |
|
Yeah, I'm backlogged and in the middle of a move right now. All the other gboards- PRs are held up as well :( |
| * |ESC/META|ENT/ALT|SPC(SYM)| |SPC(NUM)|BSPC|TAB| | ||
| * '-------------------------' '-----------------' | ||
| */ | ||
| [BASE] = LAYOUT_gergoplex(KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, MT(MOD_LCTL, KC_A), KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, MT(MOD_LCTL, KC_SCLN), MT(MOD_RSFT, KC_Z), KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, MT(MOD_RSFT, KC_SLSH), |
There was a problem hiding this comment.
| [BASE] = LAYOUT_gergoplex(KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, MT(MOD_LCTL, KC_A), KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, MT(MOD_LCTL, KC_SCLN), MT(MOD_RSFT, KC_Z), KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, MT(MOD_RSFT, KC_SLSH), | |
| [BASE] = LAYOUT_split_3x5_3(KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, MT(MOD_LCTL, KC_A), KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, MT(MOD_LCTL, KC_SCLN), MT(MOD_RSFT, KC_Z), KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, MT(MOD_RSFT, KC_SLSH), |
| * |MMB | ; | = | | = | ; | DEL | | ||
| * '-----------------' '------------------' | ||
| */ | ||
| [SYMB] = LAYOUT_gergoplex(KC_EXLM, KC_AT, KC_LCBR, KC_RCBR, KC_PIPE, KC_GRV, KC_TILD, KC_TRNS, KC_TRNS, KC_BSLS, KC_HASH, KC_DLR, KC_LPRN, KC_RPRN, KC_BTN2, KC_PLUS, KC_MINS, KC_SLSH, KC_ASTR, KC_QUOT, KC_PERC, KC_CIRC, KC_LBRC, KC_RBRC, KC_BTN1, KC_AMPR, KC_EQL, KC_COMM, KC_DOT, KC_MINS, CMB_TOG, KC_SCLN, KC_EQL, KC_EQL, KC_SCLN, KC_DEL), |
There was a problem hiding this comment.
| [SYMB] = LAYOUT_gergoplex(KC_EXLM, KC_AT, KC_LCBR, KC_RCBR, KC_PIPE, KC_GRV, KC_TILD, KC_TRNS, KC_TRNS, KC_BSLS, KC_HASH, KC_DLR, KC_LPRN, KC_RPRN, KC_BTN2, KC_PLUS, KC_MINS, KC_SLSH, KC_ASTR, KC_QUOT, KC_PERC, KC_CIRC, KC_LBRC, KC_RBRC, KC_BTN1, KC_AMPR, KC_EQL, KC_COMM, KC_DOT, KC_MINS, CMB_TOG, KC_SCLN, KC_EQL, KC_EQL, KC_SCLN, KC_DEL), | |
| [SYMB] = LAYOUT_split_3x5_3(KC_EXLM, KC_AT, KC_LCBR, KC_RCBR, KC_PIPE, KC_GRV, KC_TILD, KC_TRNS, KC_TRNS, KC_BSLS, KC_HASH, KC_DLR, KC_LPRN, KC_RPRN, KC_BTN2, KC_PLUS, KC_MINS, KC_SLSH, KC_ASTR, KC_QUOT, KC_PERC, KC_CIRC, KC_LBRC, KC_RBRC, KC_BTN1, KC_AMPR, KC_EQL, KC_COMM, KC_DOT, KC_MINS, CMB_TOG, KC_SCLN, KC_EQL, KC_EQL, KC_SCLN, KC_DEL), |
| * | F11 | F12| | | | PLY | SKP | | ||
| * '-----------------' '-----------------' | ||
| */ | ||
| [NUMB] = LAYOUT_gergoplex(KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_F1, KC_F2, KC_F3, KC_F4, KC_F5, KC_LEFT, KC_DOWN, KC_UP, KC_RGHT, KC_VOLU, KC_F6, KC_F7, KC_F8, KC_F9, KC_F10, KC_MS_L, KC_MS_D, KC_MS_U, KC_MS_R, KC_VOLD, KC_F11, KC_F12, KC_TRNS, KC_TRNS, KC_MPLY, KC_MNXT)}; |
There was a problem hiding this comment.
| [NUMB] = LAYOUT_gergoplex(KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_F1, KC_F2, KC_F3, KC_F4, KC_F5, KC_LEFT, KC_DOWN, KC_UP, KC_RGHT, KC_VOLU, KC_F6, KC_F7, KC_F8, KC_F9, KC_F10, KC_MS_L, KC_MS_D, KC_MS_U, KC_MS_R, KC_VOLD, KC_F11, KC_F12, KC_TRNS, KC_TRNS, KC_MPLY, KC_MNXT)}; | |
| [NUMB] = LAYOUT_split_3x5_3(KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_F1, KC_F2, KC_F3, KC_F4, KC_F5, KC_LEFT, KC_DOWN, KC_UP, KC_RGHT, KC_VOLU, KC_F6, KC_F7, KC_F8, KC_F9, KC_F10, KC_MS_L, KC_MS_D, KC_MS_U, KC_MS_R, KC_VOLD, KC_F11, KC_F12, KC_TRNS, KC_TRNS, KC_MPLY, KC_MNXT)}; |
| uint8_t init_mcp23018(void); | ||
|
|
||
| /* -------- LEFT HAND------RIGHT HAND ---------- */ | ||
| #define LAYOUT_gergoplex(L00, L01, L02, L03, L04, R00, R01, R02, R03, R04, L10, L11, L12, L13, L14, R10, R11, R12, R13, R14, L20, L21, L22, L23, L24, R20, R21, R22, R23, R24, L30, L31, L32, R30, R31, R32) \ |
There was a problem hiding this comment.
| #define LAYOUT_gergoplex(L00, L01, L02, L03, L04, R00, R01, R02, R03, R04, L10, L11, L12, L13, L14, R10, R11, R12, R13, R14, L20, L21, L22, L23, L24, R20, R21, R22, R23, R24, L30, L31, L32, R30, R31, R32) \ | |
| #define LAYOUT_split_3x5_3(L00, L01, L02, L03, L04, R00, R01, R02, R03, R04, L10, L11, L12, L13, L14, R10, R11, R12, R13, R14, L20, L21, L22, L23, L24, R20, R21, R22, R23, R24, L30, L31, L32, R30, R31, R32) \ |
This is a new "standardized" macro from #9562.
The purpose of this is to make this macro generic and allow users to share keymaps between keyboards with the same layout.
There was a problem hiding this comment.
@Erovia I really love the cleaniness of defining layouts with LAYOUT_kc, i.e:
[_ALPHA] = LAYOUT_kc(
// ,-------------------------------. ,-------------------------------.
Q , W , E , R , T , Y , U , I , O , P ,
// |-------+-----+-----+-----+-----| |-----+-----+-----+-----+-------|
CTL_A , S , D , F , G , H , J , K , L , CTL_CL,
// |-------+-----+-----+-----+-----| |-----+-----+-----+-----+-------|
SFT_Z , X , C , V , B , N , M ,COMMA, DOT , SFT_SL,
// '-------------------------------' '-------------------------------'
There's a comment I've found:
/*This special definition is used for S60-X keymaps that were ported from TMK
* QMK has a lot of keycodes that don't start with KC_, so using the regular KEYMAP macro is recommended
*/
#define LAYOUT_kc( \
There's actually just one non-KC keycode used in the keymap, CMB_TOG.
Also, there's a number of gergoplex-specific definitions:
#define KC_CMB_TOG CMB_TOG // A hack to allow KC_-less keycode along with KC_-ful ones
#define KC_CTL_A MT(MOD_LCTL, KC_A) // Tap for A, hold for Control
#define KC_CTL_CL MT(MOD_LCTL, KC_SCLN) // Tap for colon, hold for Control
What prevents users of a different keyboard from picking the layout above and using it? How is it supposed to be done?
Is it sufficient to add LAYOUTS = split_3x5_3 to rules.mk?
There was a problem hiding this comment.
@ddeklerk Can you suggest the best way to adjust pirj/qmk_firmware@c5403c6...prettify-gergoplex#diff-4d9b17528e05fb959c4124c0aba5b47eR27 ?
| CUSTOM_MATRIX = yes | ||
| COMBO_ENABLE = yes | ||
| EXTRAKEY_ENABLE = yes | ||
| CONSOLE_ENABLE = yes | ||
| COMMAND_ENABLE = yes | ||
| BOOTMAGIC_ENABLE = lite |
There was a problem hiding this comment.
| CUSTOM_MATRIX = yes | |
| COMBO_ENABLE = yes | |
| EXTRAKEY_ENABLE = yes | |
| CONSOLE_ENABLE = yes | |
| COMMAND_ENABLE = yes | |
| BOOTMAGIC_ENABLE = lite | |
| CUSTOM_MATRIX = yes | |
| COMBO_ENABLE = yes | |
| EXTRAKEY_ENABLE = yes | |
| CONSOLE_ENABLE = yes | |
| COMMAND_ENABLE = yes | |
| BOOTMAGIC_ENABLE = lite |
| # know what you're doing. | ||
| # | ||
| # No touchy, capiche? | ||
| SRC += matrix.c i2c_master.c |
There was a problem hiding this comment.
| SRC += matrix.c i2c_master.c |
| DDRB &= ~(1 << 0 | 1 << 4 | 1 << 5 | 1 << 6 | 1 << 7); | ||
| PORTB |= (1 << 0 | 1 << 4 | 1 << 5 | 1 << 6 | 1 << 7); | ||
|
|
||
| DDRC &= ~(1 << 6); | ||
| PORTC |= (1 << 6); | ||
|
|
||
| PORTD |= (1 << 5 | 1 << 4 | 1 << 6 | 1 << 7); | ||
| DDRD &= ~(1 << 5 | 1 << 4 | 1 << 6 | 1 << 7); | ||
|
|
||
| DDRE &= ~(1 << 6); | ||
| PORTE |= (1 << 6); | ||
|
|
||
| DDRF &= ~(1 << 0 | 1 << 7); | ||
| PORTF |= (1 << 0 | 1 << 7); |
There was a problem hiding this comment.
We rather use the GPIO control functions: https://docs.qmk.fm/#/internals_gpio_control?id=functions
Also, if this is not needed for the matrix initialization, they should be moved to keyboard_post_init_kb.
| @@ -0,0 +1,80 @@ | |||
| #include QMK_KEYBOARD_H | |||
There was a problem hiding this comment.
| #include QMK_KEYBOARD_H | |
| #include "gergoplex.h" |
| #include <stdint.h> | ||
| #include <stdbool.h> |
There was a problem hiding this comment.
| #include <stdint.h> | |
| #include <stdbool.h> |
I believe these are implicitly included. Maybe the others, too.
Test it though. :D
| @@ -0,0 +1,288 @@ | |||
| /* | |||
There was a problem hiding this comment.
Is a custom matrix really needed?
There was a problem hiding this comment.
Is there any way to get these suggested changes into their own branch so I can test them without trashing the PR? Need to verify these all work and compile
There was a problem hiding this comment.
Not sure if Github has a feature like this, but you could commit all the suggestions as one and pull in the PR into new branch on your computer.
You could check it out, fine-tune it and drop it if it's a disaster.
Feel free to ping me on QMK Discord if the above doesn't make any sense. Words are hard... :D
There was a problem hiding this comment.
Adding to @Erovia's change request for split_3x5_3 layout support, I believe this is also needed.
|
|
||
| DEBOUNCE_TYPE = eager_pr | ||
| SRC += matrix.c | ||
| QUANTUM_LIB_SRC += i2c_master.c |
There was a problem hiding this comment.
| QUANTUM_LIB_SRC += i2c_master.c | |
| QUANTUM_LIB_SRC += i2c_master.c | |
| LAYOUTS = split_3x5_3 |
noroadsleft
force-pushed
the
develop
branch
2 times, most recently
from
1d4c0cd to
65c27a3
Compare
noroadsleft
force-pushed
the
develop
branch
from
a1b96ba to
3430907
Compare
|
@Erovia I'm currently bringing this PR to shape. Is it correct that it's made against Speaking of the breaking changes, this PR (along with the others gBoards-related https://github.com/qmk/qmk_firmware/pull/germ) don't seem to fall under "modifies how QMK behaves in a way that in incompatible or potential..ly dangerous" clause. Do you think it's possible to remove it and merge normally (when it's in a good condition)? |
|
@drashna Do you think it's makes sense to remove the |
|
@pirj not all those PRs can have their label removed as they relocate a existing keyboard, which falls under our current rules for 'breaking changes'. This one, and a few of the others are newly added keyboards so might not have that restriction (dependent on changed files). |
github-actions
bot
added
the
via
|
It's ok to close this PR, I'm handling it in #10406. Sorry, I was busy with other things, so it's taking me longer, but I plan to wrap it up this year. |
|
Cheers. |
Part two of the gboards-consolidation project. The Mega PR has been separated out into smaller per-keyboard PRs.
This PR contains a single keyboard as per @zvecr , in this case GergoPlex. This code was pulled from #8262
Issues Fixed or Closed by This PR