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

number of macros #787

Open
stehlyl opened this issue Jul 8, 2024 · 5 comments
Open

number of macros #787

stehlyl opened this issue Jul 8, 2024 · 5 comments

Comments

@stehlyl
Copy link

stehlyl commented Jul 8, 2024

First thanks a lot for your work on keyd, I cannot live without it :)

I just realized that the number of macros is limited to 256. Would it be possible to increase this limit to 512 or why not even 1024 ?

@rvaiya
Copy link
Owner

rvaiya commented Jul 27, 2024

Can you elaborate on your use case? The limits were intelligently chosen to keep configs under a certain size with the goal of ultimately supporting embedded platforms.

@tkna91
Copy link
Contributor

tkna91 commented Jul 27, 2024

I came up with the alternative of replacing the symbolic link to /etc/keyd/common.
#458
If the use case cannot be handled with that, rvaiya may consider extending the restriction.

@Zite303
Copy link

Zite303 commented Jul 29, 2024

Thanks a lot for your answer. I solved my issue concerning the number of macros by modifying the behaviour of oneshotm directly in the source code so that I need less of them : im my version the clear_oneshot function is called before switching to the oneshot layer. This matters only when oneshotm is used to go to a layer when another oneshotm is defined.

Here is the change i did in keyboard.c (im not a C programmer at all, but it seems to work) :
case OP_ONESHOT:
idx = d->args[0].idx;
if (pressed) {
/* modification here : first clear to come back to main, then only activate new layer */
clear_oneshot(kbd);
activate_layer(kbd, code, idx);
update_mods(kbd, dl, 0);
kbd->oneshot_latch = 1;

The full explanation, is that im developing my own keyboard layout, that uses the concept of alternate keys. So in my config, I have a several keys associated with oneshotm macro. To give you an example, lets says we want that typing aa output au and that typing ee output eo :

[main]
a = oneshotm(layer_a,a)
e = oneshotm(layer_e,e)

[layer_a]
a = u

[layer_e]
e = o

typing aa -> outputs au as expected
however typing aea -> output aeu instead of aea :

So here we would need to add another oneshotm in the config file to prevent this to happen :

[main]
a = oneshotm(layer_a,a)
e = oneshotm(layer_e,e)

[layer_a]
a = u

[layer_e]
e = o
a = oneshotm(layer_a,a)

In other words if we have N keys associated with a oneshotm, we will need to N*N oneshotm in our config file, which requires lot of oneshotm macros. The other alternative, is to modify oneshotm as I did.

@tkna91
Copy link
Contributor

tkna91 commented Jul 30, 2024

@rvaiya I'm not sure, but is it possible to write a patch file that removes or extends the limits on the number of layers and amount of key definitions, assuming a typical x86-64 system with plenty of memory, etc.?
I imagine that would make that version available to the AUR and others.
Of course they do not need to be added to the mainline.
Or conversely, we could change the mainline and then have a patch for the embedded environment.
Or, if you have separate branches and can operate them with almost no maintenance, that might be the simplest way.

@tkna91
Copy link
Contributor

tkna91 commented Aug 17, 2024

For anyone interrested,
there is a limit at 64 character hardcoded here:
https://github.com/rvaiya/keyd/blob/master/src/macro.h#L24

#809 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants