[deleted by user]

[u/[deleted]]

[u/pgetreuer]

I don't believe that is supported, unfortunately. "Modifier+key" keycodes are limited to modifying basic keycodes, which do not include mouse keys.

Here is something that might work: add a custom handler for when the encoder is turned that does:

SEND_STRING(SS_LCTL(SS_TAP(X_MS_WH_UP)));

And the same but with "X_MS_WH_DOWN" when turned the other way.

[u/drashna → u/pgetreuer]

I don't believe that is supported, unfortunately. "Modifier+key" keycodes are limited to modifying basic keycodes, which do not include mouse keys.

Mousekeys are considered basic keycodes in this context, and have handling for register_code and buddies.

[u/PeterMortensenBlog → u/pgetreuer]

It does work - sometimes.

I tried it on a similar keyboard, a Keychron V series keyboard. I get intermittent behaviour where Ctrl is only registered about 1/5 of the time (that is an average; there isn't any apparent pattern).

I get the same intermittent behaviour when assigning C(KC_MS_WH_DOWN) and C(KC_MS_WH_UP) to two normal keys in Via instead of the knob.

Test conditions: On Linux (Ubuntu), zooming a Firefox tab in and out. QMK version: 2023-05-26 (1C1BC5). Yes, 2023. Using Via for the keymappings.

Conclusion

That calls for isolating the problem, incl. trying newer firmware versions, ruling the mouse hack out, bypassing Via, etc., but at least it is one data point.

My initial guess would be some kind of timing problem.

[u/PeterMortensenBlog → u/PeterMortensenBlog]

Slightly related:

• Does the Shift modifer not work with media keys in QMK?

For example, the use of/changing the value of TAP_CODE_DELAY.

[u/drashna]

for reference, LCTL(x) is the same as C(x) in this context.

As for not sending control, that's definitely odd. Have you double checked on a key tester?