Use Capslock toggle Chinese and English on macOS

[hiimyusheng]

Hi, I found that qmk firmware use capslock change input between chinese and english on macOS has a issue In a normal case, press capslock will toggle chinese and english, and english input will be lowercase If want to input uppercase you just long press it, the input will be uppercase but in qmk firmware, press capslock to change input from chinese to english, it also change english to uppercase, it should be lowecase until i long press. and in qmk firmware, long press will cause the input always be english, only if i long press again. it seems like a bug, or just my settings is wrong?

[filterpaper]

The feature you mentioned is based on timing detection of the operating system, not a bug. To enable better detection of Caps Lock on Mac OS, try adding the following delay to your config.h. Increment it slightly till the caps lock detection works for the feature you mentioned:

#define TAP_CODE_DELAY 5

The value above worked did work correctly to tigger language change on tap, and upper case on long press.

[hiimyusheng]

HI, my keyboard is gmmk pro the default setting is #define TAP_CODE_DELAY 10 I try to increce it, 11-13 the behavior as same as 10, above 13 it will not trigger language change when I tap the caps it always in English I also asked chinese keyboard community, there is people has the same issur same to me, it seems like all qmk firmware on macOS's issue?

[filterpaper]

Have you tried reducing to 5? I can confirm this not a QMK firmware with macOS issue because I have tested QMK with MacOS and it works as described with the right timing.

For context TAP_CODE_DELAY configures the timing delay between key down and key up. Apple controls the hardware and software; they have likely fixed a timing on both to detect difference between short press and long press of caps lock. So you need to find the TAP_CODE_DELAY sweet spot that MacOS will register as short press.

[drashna]

For capslock, it uses TAP_HOLD_CAPS_DELAY

[lokher]

According to my test, it seems to be a bug of macOS handling NKRO input report. Turning off NKRO would solve it. Sending keys report via NKRO report interface only when more than 6 keys are pressed may be a better solution, current qmk firmware always sends keys report via NKRO report interface when NKRO is enabled.

[lokher]

I feedbacked this issue to Apple and am waiting for their response...

[szcharlesji]

Seems that this issue has not been solved yet, for now, my solution is to remap caps lock to a macro in VIA.

Macro:{KC_LCTL,KC_SPC}

This switches your input source only. But the tradeoff is that you cannot use it for a caps lock anymore.

[antonu17]

According to my test, it seems to be a bug of macOS handling NKRO input report. Turning off NKRO would solve it. Sending keys report via NKRO report interface only when more than 6 keys are pressed may be a better solution, current qmk firmware always sends keys report via NKRO report interface when NKRO is enabled.

Indeed. I cloned https://github.com/Keychron/qmk_firmware and flashed qmk flash -kb keychron/q1/rev_0107 -km default with NKRO_ENABLE = no and Caps Lock is now working properly for switching layouts.

Before doing this I also tried to set TAP_CODE_DELAY to 5 and TAP_HOLD_CAPS_DELAY to 200 as recommended in https://github.com/qmk/qmk_firmware/blob/master/docs/config_options.md - these parameters didn't help.

cc @lalalademaxiya1 cc @fauxpark

[imEgo]

According to my test, it seems to be a bug of macOS handling NKRO input report. Turning off NKRO would solve it. Sending keys report via NKRO report interface only when more than 6 keys are pressed may be a better solution, current qmk firmware always sends keys report via NKRO report interface when NKRO is enabled.

Indeed. I cloned https://github.com/Keychron/qmk_firmware and flashed qmk flash -kb keychron/q1/rev_0107 -km default with NKRO_ENABLE = no and Caps Lock is now working properly for switching layouts.

Before doing this I also tried to set TAP_CODE_DELAY to 5 and TAP_HOLD_CAPS_DELAY to 200 as recommended in https://github.com/qmk/qmk_firmware/blob/master/docs/config_options.md - these parameters didn't help.

cc @lalalademaxiya1 cc @fauxpark

disable nkro works great, you can define a key as NK_TOGG for nkro on/off switch, after turn off nkro caps lock works perfect on macOS

[irebane]

According to my test, it seems to be a bug of macOS handling NKRO input report. Turning off NKRO would solve it. Sending keys report via NKRO report interface only when more than 6 keys are pressed may be a better solution, current qmk firmware always sends keys report via NKRO report interface when NKRO is enabled.

Indeed. I cloned https://github.com/Keychron/qmk_firmware and flashed qmk flash -kb keychron/q1/rev_0107 -km default with NKRO_ENABLE = no and Caps Lock is now working properly for switching layouts.

Before doing this I also tried to set TAP_CODE_DELAY to 5 and TAP_HOLD_CAPS_DELAY to 200 as recommended in https://github.com/qmk/qmk_firmware/blob/master/docs/config_options.md - these parameters didn't help.

cc @lalalademaxiya1 cc @fauxpark

Used this method for my US ANSI Knob Q1 V2 and after flashing everything seems to be working fine and NKRO is disabled but VIA no longer detects the keyboard, noticed it when my RGB was no longer controlled by FN+Knob and decided to check keymap. Is there any deeper manual about settings in rules.mk file?

[fauxpark]

VIA won't work when you flash the default keymap.

[irebane]

VIA won't work when you flash the default keymap.

Make sense but with VIA keymap it throws a error about EPROM size

`Compiling: quantum/dynamic_keymap.c quantum/dynamic_keymap.c:47:13: note: '#pragma message: 2047 > ((1024) - 1)' 47	# pragma message STR(DYNAMIC_KEYMAP_EEPROM_MAX_ADDR) " > " STR((TOTAL_EEPROM_BYTE_COUNT - 1))	^~~ quantum/dynamic_keymap.c:48:6: error: #error DYNAMIC_KEYMAP_EEPROM_MAX_ADDR is configured to use more space than what is available for the selected EEPROM driver 48	# error DYNAMIC_KEYMAP_EEPROM_MAX_ADDR is configured to use more space than what is available for the selected EEPROM driver	^~~~~ [ERRORS]

gmake[1]: [builddefs/common_rules.mk:456: .build/obj_keychron_q1_rev_0107_via/quantum/dynamic_keymap.o] Error 1 gmake: [Makefile:413: keychron/q1/rev_0107:via:flash] Error 1`

[lokher]

VIA won't work when you flash the default keymap.

Make sense but with VIA keymap it throws a error about EPROM size

Compiling: quantum/dynamic_keymap.c quantum/dynamic_keymap.c:47:13: note: '#pragma message: 2047 > ((1024) - 1)' 47 | # pragma message STR(DYNAMIC_KEYMAP_EEPROM_MAX_ADDR) " > " STR((TOTAL_EEPROM_BYTE_COUNT - 1)) | ^~~~~~~ quantum/dynamic_keymap.c:48:6: error: #error DYNAMIC_KEYMAP_EEPROM_MAX_ADDR is configured to use more space than what is available for the selected EEPROM driver 48 | # error DYNAMIC_KEYMAP_EEPROM_MAX_ADDR is configured to use more space than what is available for the selected EEPROM driver | ^~~~~ [ERRORS] | | | gmake[1]: *** [builddefs/common_rules.mk:456: .build/obj_keychron_q1_rev_0107_via/quantum/dynamic_keymap.o] Error 1 gmake: *** [Makefile:413: keychron/q1/rev_0107:via:flash] Error 1

Did you compile with playground branch of Keychron fork?

[irebane]

VIA won't work when you flash the default keymap.

Make sense but with VIA keymap it throws a error about EPROM size Compiling: quantum/dynamic_keymap.c quantum/dynamic_keymap.c:47:13: note: '#pragma message: 2047 > ((1024) - 1)' 47 | # pragma message STR(DYNAMIC_KEYMAP_EEPROM_MAX_ADDR) " > " STR((TOTAL_EEPROM_BYTE_COUNT - 1)) | ^~~~~~~ quantum/dynamic_keymap.c:48:6: error: #error DYNAMIC_KEYMAP_EEPROM_MAX_ADDR is configured to use more space than what is available for the selected EEPROM driver 48 | # error DYNAMIC_KEYMAP_EEPROM_MAX_ADDR is configured to use more space than what is available for the selected EEPROM driver | ^~~~~ [ERRORS] | | | gmake[1]: *** [builddefs/common_rules.mk:456: .build/obj_keychron_q1_rev_0107_via/quantum/dynamic_keymap.o] Error 1 gmake: *** [Makefile:413: keychron/q1/rev_0107:via:flash] Error 1

Did you compile with playground branch of Keychron fork?

Thank you, playground branch has compiled fine. qmk flash -kb keychron/q1/q1_ansi_stm32l432_ec11 -km via

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

[github-actions[bot]]

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know. // [stale-action-closed]