Skip to content
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.

Sign up for GitHub

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

Jump to bottom

bepo layer is qwerty not bepo. #3079

Closed
EricGebhart opened this issue May 29, 2018 · 21 comments
Closed

bepo layer is qwerty not bepo. #3079

EricGebhart opened this issue May 29, 2018 · 21 comments
Labels
discussion help wanted keymap question

Comments

@EricGebhart
Copy link
Contributor

I have an ergodox ez.
I flashed my own firmware over a year ago, but the bepo layer never worked.

I just redid my firmware again today, I had hoped I had figured something out, but no.
I'm using the current version of qmk.

My firmware compiles and works as expected except for my second layer.

I have a dvorak layer at 0 and a bepo layer at 1. I invoke it by changing it to the default layer, ie. DF().

But instead of bepo I get qwerty. I don't have a qwerty layer in my firmware.
I used the bepo keymap.h and mostly copied the bepo keymap into my own.

Looking at the bepo code I dont even see how it can work...

What am I missing ?
@drashna
Copy link
Member

drashna commented May 29, 2018 •
edited
Loading

What is your OS's actual keyboard layout?

If it's not qwerty, that may be why.

Also, if you used this: https://github.com/qmk/qmk_firmware/blob/master/quantum/keymap_extras/keymap_bepo.h
That may be why. It remaps things, so you've got to be careful.

Also, have you checkout out this: https://github.com/qmk/qmk_firmware/blob/master/layouts/community/ergodox/bepo/keymap.c

It may be closer to what you're looking for, actually.

@EricGebhart
Copy link
Contributor Author

I'm on linux and my keyboard is set to qwerty. I Also use a kinesis, so that is what I'm used to doing. I used the first one. I've always suspected that was the wrong way around. The second one looks like what I need.

I'll give that a shot. It looks more like what I would have expected.

Thanks!!

@EricGebhart
Copy link
Contributor Author

After looking at the code and comments it seems that a full bepo keyboard isn't really possible on a qwerty mapping. Even the Azerty mapping seems lacking.

Would it be better to go with unicode so that all the characters are available ?

@EricGebhart
Copy link
Contributor Author

I realize this has as much to do with the keyboard on the OS as anything. It's like when I switch my laptop to dvorak, then forget and try to type with my dvorak kenisis which expects an en-US os keyboard.

It seems like that in order to get a real functioning bepo ergodox it needs to map to a bépo keyboard or at least an extended Latin keyboard that has all the letters I need.

But then, that makes having a dvorak keyboard difficult because the normal keys and shifted keys are different.

Is there a way in qmk to define what a key should do with each modifier? At least, normal, shifted, alt gre/r-alt, ctrl?

Or maybe it is better to do a software keyboard, in which case a qwerty ergodox layer would be the right thing... I think.

@drashna
Copy link
Member

drashna commented May 30, 2018

I realize this has as much to do with the keyboard on the OS as anything

Yup. In fact, I've seen this a lot, actually. There isn't a good solution for ... well non-US implementations. And that has more to do with standardization, than anything else. Because most of the non-latin characters don't have their own scancode, and rely on the OS for management. Which makes KB firmware that much more difficult.

Would it be better to go with unicode so that all the characters are available ?

Maybe. but even that is a mine field, as each OS manages unicode different. And Windows handles it pretty poorly.

Is there a way in qmk to define what a key should do with each modifier? At least, normal, shifted, alt gre/r-alt, ctrl?

Yes. https://docs.qmk.fm/#/feature_advanced_keycodes?id=modifier-keys

RALT(kc) if what you want for AltGr.

Or maybe it is better to do a software keyboard, in which case a qwerty ergodox layer would be the right thing... I think.
I think this is going to be the best bet, no matter what you do.

Though, I've seen a few people that well ... do this, and then have a "software layer", so that if the OS is handling this. .. they have a layer they can fall back to... rather than a nightmare.

This is probably going to be a good idea for you, as well.

@EricGebhart
Copy link
Contributor Author

EricGebhart commented May 30, 2018 via email

@EricGebhart
Copy link
Contributor Author

sorry about the inclusions in that last post, I did it from my phone...

So I've confirmed that the bepo layer I have works with a bepo keyboard on the OS. Of course that completely breaks my dvorak layer. So I've created a dvorak layer based on the bepo keys. That also seems to work.

Is this the path you were thinking was the best route ?

Now, I want to have a key which selects a different layer depending on if the current default base is on us dvorak or the fr versions dvorak or bepo what is the best way to do that ?

The explanation of function_action is a bit vague. It says to use fn_actions and then says it's better not to. It's also unclear to me if the state structure is available or not.

I know I can create a tap_dance_fn that receives the state, because I've done that. What I'd like is to have a key call a function with the state so I can look at the default layer and then choose the appropriate layer to invert, toggle, move.

This all because I have a dvorak layer for en-us, and dvorak and bepo layers for fr-bepo. So the other layers may or may not need to be in sync with that.

Sorry this is out of context for the original issue, which seems to be resolved. The keymap I was using for bepo was intended for use on top of a bepo software layer in the OS and that does indeed work.

@EricGebhart
Copy link
Contributor Author

Is there a way to do this?

MT(LM(foo, LGUI), kc)

@drashna
Copy link
Member

drashna commented May 31, 2018

Yeah, it was the bath that I thought was probably going to be best.

Now, I want to have a key which selects a different layer depending on if the current default base is on us dvorak or the fr versions dvorak or bepo what is the best way to do that ?

The best way to do this is to set default layers.
You can use the "DF()" keycode, but this isn't semi-permanent. (eg, it won't last after power loss). Not without some "help".
That help being onef of two options:

uint32_t default_layer_state_set_kb(uint32_t state) {
  eeconfig_update_default_layer(state);
  return state;
}

This method has the advantage of the fact that you can just use "DF(x)" in your keymap, and it will handle everything for you.

The other option is to use set_single_persistent_default_layer in a custom keycode:
https://github.com/qmk/qmk_firmware/blob/master/keyboards/planck/keymaps/default/keymap.c#L194-L205

Both accomplish the same thing, but in different ways.

For the fn_action stuff, I can't help much here, since I actually have this disabled in my firmware, since it errors out when compiling, if it's present (I use LTO, so ...).
But basically, most of the "ACTION_whatever" functions are already wrapped into keycodes. So, you can find a keycode that does whatever a function does, usually.

And no, that's fine, conversation evolve. And this is still relevant to the original issue, IMO. So no problem, at all.
And more to the point, somebody with the same issue may want to know how you did handled this too.

@drashna
Copy link
Member

drashna commented May 31, 2018

Is there a way to do this?
MT(LM(foo, LGUI), kc)

No. Not without a custom keycode.

both only support "basic" keycodes. Eg, codes from this list:
https://docs.qmk.fm/#/keycodes_basic

@EricGebhart
Copy link
Contributor Author

yea. So I know I have to write my own. It's not clear in the doc about action_fn. Needed or not. It says to use it, then that it's better not to.

I'm slowly finding the code underneath. But haven't gotten to the MOD code yet.
I wrote a tap dance function to invert multiple layers. That was easy. But I haven't found what I need yet to do a custom LM_T(layer, mod, kc) function yet. I guess LT_T(layer, kc) would be first, then LM_T(layer, mod, kc).

@drashna
Copy link
Member

drashna commented May 31, 2018

Just out of curiosity, where do you see the action_fn in the docs?

Also... yeah, QMK is based on TMK, and a lot of this stuff is left overs from TMK. And "we" haven't cleaned up everything.

@EricGebhart
Copy link
Contributor Author

It's in the keymap overview.

yea, I found most of what I was looking for in tmk_common. But I still don't have a solid understanding of the code yet. I'm missing the piece that connects the key/action codes and the actual code.

On the other hand I think I can can get what I want with the advanced tap dance example.

I'd be willing to help out. But I don't know that I know enough yet. I should look through the issues for things with the doc and whatever else I might be able to do.

@EricGebhart
Copy link
Contributor Author

So that is just a replacement of the usual default_layer_state_set() in the action_layer.c ? correct ? So I'm just stomping on the original which does nothing but return state...

@EricGebhart
Copy link
Contributor Author

@drashna
I've figured out a lot of this, but I'm having trouble with my custom keycodes. I always seem to get 2. There's probably a better way to do this but this is the function I have.
I'm also not sure that everything I'm doing is necessary. But I do know that in order to get a key that does the right thing I need a code and the mods to go with it for both the shifted and unshifted version of my new key.

void send_keycode(int unshifted, int unshifted_mods, int shifted, int shifted_mods){
  uint8_t tmp_mods = get_mods();
  bool is_shifted = ( tmp_mods & (MOD_BIT(KC_LSFT)|MOD_BIT(KC_RSFT)) );
  // need to turn of the shift if it is on.
  unregister_mods((MOD_BIT(KC_LSFT)|MOD_BIT(KC_RSFT)));
  if(is_shifted){
    register_mods(shifted_mods);
    register_code(shifted);
    unregister_code(shifted);
    unregister_mods(shifted_mods);
  } else{
    register_mods(unshifted_mods);
    register_code(unshifted);
    unregister_code(unshifted);
    unregister_mods(unshifted_mods);
  }
  clear_mods();
  register_mods(tmp_mods);
}

As an example, here is what actually works for the "1" key.

  switch (keycode) {
  case DB_1:
    send_keycode(BP_DQOT, MOD_LSFT, BP_DCRC, MOD_LSFT);
    break;

Any suggestions would be appreciated.

@EricGebhart
Copy link
Contributor Author

OK. Never mind. It looks like I'm down to small problems. It seems altgre is not ralt so those characters don't work in bépo or my Dvorak on bépo. There are a few characters that I have no idea how to type if I could #&_ . When I figure out altgre the rest of them should work.

@EricGebhart
Copy link
Contributor Author

I seem to have everything working. The bépo layer needs some love. It doesn't fit very well. I'll do a pull request soon.

@drashna
Copy link
Member

drashna commented Jun 6, 2018

awesome!

And please do reference this issue in the PR, so others can find it.

@EricGebhart EricGebhart mentioned this issue Jun 8, 2018
Merged
@EricGebhart
Copy link
Contributor Author

I have submitted pull request #3149 which creates a firmware that handles all of these questions.

@jreese802
Copy link

@EricGebhart Should this issue be closed now that the PR has been merged? Are there any remaining issues?

@EricGebhart
Copy link
Contributor Author

Yes. This issue has been resolved and is well documented here and in the merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
discussion help wanted keymap question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@drashna @EricGebhart @jreese802