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.

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

[Bug] Applying ignore_mod_tap_interrupt inside info.json doesn't apply #20656

Closed
2 tasks
miropls opened this issue May 1, 2023 · 2 comments
Closed
2 tasks

Comments

@miropls
Copy link

miropls commented May 1, 2023

Describe the Bug

Was ripping my hair out over this, but it turns out for whatever reason, ignore_mod_tap_interrupt does not seem to apply through the info.json configuration. I have been creating a default configuration for a new keyboard, and decided on trying to do everything possible through data driven configuration. Here is the relevant section of my info.json:

"tapping": {
    "ignore_mod_tap_interrupt": true,
    "term": 200,
    "quick_tap_term": 200,
    "tap_code_delay": 10
},

This would not remove the default behavior of mod-taps as anticipated. Finally I decided trying out enabling ignore_mod_tap_interrupt through the config.h file and removing it from the info.json file. After flashing the firmware on my controllers, the mod-taps would behave just as expected.

To reproduce this bug, add "ignore_mod_tap_interrupt": true to a keyboards info.json, and make sure it isn't present in config.h.
Only tested this on my new Emilia54 build, so I can not confirm whether this bug is present on other keyboards as well.

I am aware that ignore_mod_tap_interrupt is to be the new default behavior for mod-taps and that it has been depracated, however, I do feel like this is something worth looking at for now, until this phasing comes to pass.

Keyboard Used

emilia54/default (not in the upstream repo yet)

Link to product page (if applicable)

No response

Operating System

Ubuntu 22.04 (WSL2 inside Win10)

qmk doctor Output

❯ qmk doctor                           
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.2
Ψ QMK home: /home/miropls/qmk_firmware
Ψ Detected Linux (WSL, Ubuntu 22.04.2 LTS).
Ψ Git branch: emilia54
Ψ Repo version: 0.20.5
⚠ Git has unstashed/uncommitted changes.
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 10.3.1
Ψ Found avr-gcc version 5.4.0
Ψ Found avrdude version 6.3-20171130
Ψ Found dfu-programmer version 0.6.1
Ψ Found dfu-util version 0.9
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2023-01-03 19:29:26 +0000 --  (0062927e3)
Ψ - lib/chibios-contrib: 2023-01-11 16:42:27 +0100 --  (a224be15)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go, but minor problems were found

Is AutoHotKey / Karabiner installed

  • AutoHotKey (Windows)
  • Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

@sigprof
Copy link
Contributor

sigprof commented May 1, 2023

Apparently the support for the tapping.ignore_mod_tap_interrupt key in JSON was removed in #15741 (the option is not rejected by the schema, but gets effectively ignored, because there is no config.h mapping for it). And in the develop branch the underlying IGNORE_MOD_TAP_INTERRUPT define no longer exists since #20211, so restoring that option in JSON now is mostly pointless.

@miropls
Copy link
Author

miropls commented May 1, 2023

Ah, it's that far along already though not in the master branch yet. Not using the dev branch would then explain why the default behavior has not changed when imti is not explicitly defined.

I'll close this ticket in that case, I had figured it would've been a bug, but it seems it's just a case of tl;dr from the OP. 😅 Though, admittedly, there's no way of knowing when refering to the master branches keyboard.jsonchema file as it is present there. Thank you very much for the input @sigprof! Much appreciated!

@miropls miropls closed this as completed May 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants