Closed leshow closed 7 years ago
Looking at the default keymap.c vs the one generated by the EZ configurator default/keymap.c:
case RGB_SLD:
if (record->event.pressed) {
#ifdef RGBLIGHT_ENABLE
rgblight_mode(1);
#endif
}
return false;
from ez configurator
case RGB_SLD:
if (record->event.pressed) {
rgblight_mode(1);
}
return false;
break;
}
If I add this ifdef the EZ layout builds properly using make-infinity
.
the EZ also is missing a blank function:
// Runs just one time when the keyboard initializes.
void matrix_init_user(void) {
};
is this function necessary? I was able to build for the infinity without it.
I have the EZ configurator layout built now using make ergodox-infinity. I'm worried I missed something and I'll brick my device if I flash it. Do I have anything to worry about? Will qmk automatically change the LCD when I switch layers, etc?
The keymap() object is also slightly different between them. For example:
KEYMAP(KC_EQUAL,KC_1,KC_2,KC_3,KC_4,KC_5,KC_ESCAPE,KC_DELETE,KC_Q,KC_W,KC_E,KC_R,KC_T,TG(4),GUI_T(KC_TAB),KC_A,KC_S,KC_D,KC_F,LT(3,KC_G),KC_LSHIFT,CTL_T(KC_Z),KC_X,KC_C,KC_V,KC_B,MO(1),KC_LGUI,KC_LALT,KC_GRAVE,MO(3),KC_LCTL,KC_INSERT,KC_CAPSLOCK,KC_HOME,KC_BSPACE,KC_DELETE,KC_END,MO(2),KC_6,KC_7,KC_8,KC_9,KC_0,KC_MINUS,MO(4),KC_Y,KC_U,KC_I,KC_O,KC_P,KC_BSPACE,KC_H,KC_J,KC_K,KC_L,LT(2,KC_SCOLON),GUI_T(KC_QUOTE),MO(1),KC_N,KC_M,KC_COMMA,KC_DOT,CTL_T(KC_SLASH),KC_LSHIFT,KC_LEFT,KC_DOWN,KC_UP,KC_RIGHT,KC_LGUI,KC_LALT,CTL_T(KC_ESCAPE),KC_PGUP,KC_PGDOWN,KC_ENTER,KC_SPACE)
As far as I know, the RGB stuff won't work on ARM, so adding the ifdef or removing the rgblight line should allow things to work :)
The blank function isn't necessary - it's just there in case you'd like to add something to it, but it doesn't hurt to have.
I don't think it's possible to brick ARM by flashing the wrong keymap (it looks like this one will work though), but I'm not the most experienced in ARM right now.
I don't know if QMK's setup to control the LCD on the infinity right now unfortunately!
Thanks. So I was able to flash the firmware and everything appears to be working except for the LCD screens. There is no light coming from them and they aren't displaying anything.
I have a branch on my fork of qmk that uses the visualizer files to change the background color and display the layer name on the LCD screen, based on @fredizzimo 's TMK fork. I haven't taken the time to do more than see what works. I'm waiting for the new effects system he is working on to do more than that.
@r2d2rogers awesome! I may try flashing yours then. Do I just build how I normally would with creating a keymaps.c and running make, etc? I don't want anything fancy, I'd just like to see the layer number and have the colour change.
Are you waiting for the 'effects system' to be integrated into QMK or in fredizzimo's TMK fork? Is there any timeline for this stuff making it's way in to QMK?
The whole reason I wanted to flash this is because the KLL firmware doesn't seem to support dual-role keys, and I think they are essential. I'd prefer not to sacrifice my LCD for them though.
Dual role is exactly what I jumped over here for myself. It's the r2d2rogers branch of my fork of qmk_firmware. I was waiting till I filled in a bit more of the spaceFN style layers before I submitted to a pull request.
For the dual role keys, see how I'm using what would be caps lock for a ctrl/esc, and the right hand thumb key that is space and momentary layer, for the spaceFN I was talking about.
Edit: Forgot a question, fredizzimo is working on the effects system for qmk.
@r2d2rogers I have a keymap.c with my own layout an dual role keys set up already. Can I not just overwrite your keymap in ergodox/keymaps/r2d2rogers
and then flash?
That should work, sorry, didn't read up top and see that you had already gotten a keymap setup.
Regarding the original bug. The plan is to have either empty implementation or some kind of emulation of the Ergodox features. So in this case you shouldn't need to add #ifdefs
around rgblight_mode
. Many other functions are already implemented as dummies, but this function is not for some reason. Is there no keymap in the repository that actually uses it? Since in that case, it should have caused errors in our continous integration system as well.
In any case, I will add an empty implementation to make it work without changes.
I have an Ergodox Infinity, one of the newer ones with USB-C & LCD screen. I read your readme so I know layouts inter-operate between the infinity/ez.
The EZ online configurator (http://configure.ergodox-ez.com/keyboard_layouts/) is superior to the input club and massdrop one in the number of options it provides. I wanted to take the keymap generated from it and flash it to my infinity. I downloaded the source generated from the online configurator, made a new dir in
keymaps
calledminelayout
, and put the source in that dir askeymap.c
.I then ran
make infinity-minelayout
and got this error: