search

TeXitoi / keyberon

A rust crate to create a pure rust keyboard firmware.
MIT License
1.07k stars 78 forks source link

Additional configuration for HoldTap #33

Closed octol closed 3 years ago

octol commented 4 years ago

To be able to use home row mods it's useful to able to tweak HoldTap. For example like IGNORE_MOD_TAP_INTERRUPT and PERMISSIVE_HOLD in QMK.

@TeXitoi Proposition:

The different behaviors:

Also, we can add a tap_hold_duration corresponding to the maximal time within if you tap and hold the key, it will do the tap action, and stay holded, to allow holding the tapping behavior. (moved in #37)

It can be modeled as:

pub enum HoldTapConfig {
    Default,
    HoldOnOtherKeyPress,
    PermissiveHold,
}

pub enum Action {
    // ...
    HoldTap {
        hold: &'static Action,
        tap: &'static Action,
        timeout: u16,
        tap_hold_interval: u16,
        config: HoldTapConfig,
    },
}

That's a breaking change.

TeXitoi commented 4 years ago

Can you specify the different behavior, and explain who it improves the experience. The doc is quite obscure, and I always see people saying "I've modified randomly these parameters until I was satisfied".

Having a clear specification will help developping this feature, or open the discution to find something even better.

octol commented 4 years ago

I think this probably needs to be driven by usage experience, to find out what works. I'm will start experimenting with home row mods on my keyseebee to get some experience.

Let's start with IGNORE_MOD_TAP_INTERRUPT, which seems to be the most important one for home row mods with QMK. If I understand it correctly, by default a sequence like 

    SFT_T(KC_A) Down
    KC_X Down
    SFT_T(KC_A) Up
    KC_X Up

will trigger SHIFT+a SHIFT+x even if faster than tapping term. Setting IGNORE_MOD_TAP_INTERRUPT you get the more straightforward behaviour where SHIFT+a SHIFT+x is only triggered if the modtap key is held for the entire tapping term.

How does keyberon modtap behave for such rolling combo situations?

octol commented 4 years ago

See also: https://github.com/qmk/qmk_firmware/issues/8971 and the linked table https://docs.google.com/spreadsheets/d/1IaaOMbl6zLBb5Jswyr90Lp9hGx3xIyugVSfD_oBk4po/edit#gid=0

TeXitoi commented 4 years ago

I suppose you mean SHIFT+x. And it seems strange for me, if you roll, you would want ax.

In keyberon everything depend on the time the HoldTap key is holded, independently of any other keys. The other keys wait for the HoldTap to choose it's behavior, to keep key order.

TeXitoi commented 4 years ago

I think keyberon behave like the 2 first columns of the linked table.

octol commented 4 years ago

Well this is probably related to typing style. While playing around with modtap I have indeed realized that I typically roll my combos on a normal keyboard. Using modtap I've had to forcibly try to rewire my muscle memory to make it work. Looking at the linked table and the myriad ways of configuring modtap in QMK the purpose is probably to be able to fully tweak the behaviour to match the typist (rather then the other way around).

As an example I've noticed that my fingers behave differently where my pinky seems to be a lot slower in releasing a mod. The effect isn't noticeable on a standard keyboard, but very much so when using modtap.

An interesting case: https://www.reddit.com/r/ErgoMechKeyboards/comments/hdyw8c/111wpm_on_a_dactyl_manuform_with_homerow_mods_and/ which seems to do a lot of tweaking on a per key basis to make it work

octol commented 4 years ago

But yeah, at this point I have no concrete suggestions of how it would be useful to configure modtap. But at the same time, without being able to tweak it, it's difficult to tell what works "for me". And you are right in that a lot of people probably fiddle blindly with modtap settings in QMK until they get something that works for them

TeXitoi commented 4 years ago

So, as of today, keyberon is like with IGNORE_MOD_TAP_INTERRUPT. It seems a saner default to me, and is consistent with the default behavior of QMK's LT behavior. You also have per key timeout.

I think IGNORE_MOD_TAP_INTERRUPT is very popular because it allow rolling within the delay to do the tap behavior, as, when you type rapidly, you always press the next key before releasing the previous.

I think we can search the different behavior proposed by QMK, and trying to expose some comprehensive configuration flags. Then, when we have a clear proposition, we can implement a first subset, and experiment.

Note that I don't use home row modifiers, and that I think it will not suit my needs, as I use the BÉPO layout, a Dvorak like layout, making the home row keys highly used, and thus not really usable for home row modifiers.

I personally use LayerTap on the rest position of the thumbs:

octol commented 4 years ago

So, as of today, keyberon is like with IGNORE_MOD_TAP_INTERRUPT. It seems a saner default to me, and is consistent with the default behavior of QMK's LT behavior. You also have per key timeout.

Agree, and I think this default takes you pretty far too. Probably even enough for the majority

TeXitoi commented 4 years ago

OK, so I think I managed to extract the different behavior QMK propose, without taking into account the different timings. Basically, looking at the LT features, as the MT features have a behavior corresponding to one of LT behavior, with possibly a different timing.

So the alternatives:

It can be modeled as:

pub enum HoldTapConfig {
    Default,
    HoldOnOtherKeyPress,
    PermissiveHold,
}

pub enum Action {
    // ...
    HoldTap {
        hold: &'static Action,
        tap: &'static Action,
        timeout: u16,
        tap_hold_interval: u16,
        config: HoldTapConfig,
    },
}

That's a breaking change.

The behavior I want for my enter key is HoldOnOtherKeyPress.

We can change the names if you have a better idea, I just retaken the QMK names.

What do you think?

octol commented 4 years ago

I think it looks good! And reusing the QMK names I think makes sense unless there is a good reason for it.

And a quick follow-up, should we add functionality corresponding to RETRO_TAPPING and TAPPING_FORCE_HOLD while we're making a breaking change? These probably are simpler

TeXitoi commented 4 years ago

RETRO_TAPPING doesn't really fit in keyberon model, as as soon as the timeout is passed, the hold action is done.

For TAPPING_FORCE_HOLD, I was thinking of something like an additional field tap_hold_interval: u16 that correspond to the maximal time between the tap release and the next press for tap action be activated directly. 0 would be equivalent do the feature disabled. Not sure of the name.

octol commented 4 years ago

tap_hold_interval seems fine too me!

TeXitoi commented 4 years ago

I've updated the spec. Ready to be implemented. If anyone start working on it, please leave a comment here.

I might give it a shot later if I have some time and it's not started by someone.

gilescope commented 4 years ago

Was going to mention retrotaps - they sound good. I guess there’s no harm in sending event shift down then shift up, then also immediately following a char - that would be the equivalent of a retrotap.

TeXitoi commented 4 years ago

Well, they don't seems that good in practice https://precondition.github.io/home-row-mods#home-row-mods-order

I think better to put a long timeout than using retro tap.

TeXitoi commented 4 years ago

He has removed its blog post that seems to be a wip. Here is what I wanted to link: https://github.com/precondition/precondition.github.io/blob/b5d08e13da2ca75b10c3e58226dfe030d4faa4ea/_posts/2020-11-01-home-row-mods.md#retro-tapping

octol commented 4 years ago

I've updated the spec. Ready to be implemented. If anyone start working on it, please leave a comment here.

Sorry which spec is this referring to? Didn't spot any in the repo?

TeXitoi commented 4 years ago

Top post

TeXitoi commented 3 years ago

Working on it.