This causes all one shot that were sticking to be clearer if no keys …

[lgnakano]

…are pressed for a specified amount of time.

[lgnakano]

This is an extra timeout to clear any sticky modes. This is useful if you walk away from the keyboard and forgot which mods were active. UOSL (https://community.keyboard.io/u/uosl) had worked on that with me, but I am not sure if it was suggested as a pull request. If you find useful AND you think others may do so, feel free to merge.

[gedankenexperimenter]

Apart from largely administrative issues (code style & DCO), this change is missing one crucial element: start_time_ would need to be changed from uint16_t to uint_32_t—or, perhaps preferably (I'm not sure), a different timeout mechanism should be used. On keyboards with generously-sized MCUs (e.g. Model100), using 32-bit integers is generally fine, but on the AVR boards, every little bit helps. I want to suggest storing the timeout as an integer number of seconds (or perhaps even minutes?), and keep a separate count of seconds since the last one-shot key became sticky. That comparison wouldn't need to compensate for integer overflow (unless you consider a timeout of greater than 18 hours to be reasonable, assuming the ttl and count are stored as 16-bit integers). This alternative approach might be better for the smaller MCUs, but it might just be simpler to increase the size of start_time_ and use just the one timeout-checking function.

[gedankenexperimenter]

This change would also need documentation and a testcase. @lgnakano, if you'd like any guidance on these things, I'm happy to assist.

[lgnakano]

Thanks for the reply, Michael. You are absolutely right. The only reason why it seemed to work for me is because I had tried to test with a short timeout of 60 seconds. I changed star_time_ to uint32_t, and that made it work. I also noticed that the increase in size for the binary was a small fraction for the model 100, but it was bigger for the model 01. I got lucky: I got to 99% of program storage space if I disable EEPRom Keymap, DynamicMacros, LayerNames, NumPad, Steno, SpaceCadet. I am at 28540 out of 28672 if I use the non-working uint16_t, and at 28658 bytes if I use the correct uint32_t, so at least on my case I can afford the extra 118 bytes, but I do see the point of saving every byte: I have 14 bytes left of program storage space. I am not sure why I cannot connect the model 01 to Chrysalis, but I am happy enough that the models 100 work properly... Or so I thought. Suddenly, one of my model 100s refuses to connect to any computers (USB device failed to register or something of this sort). I am unable to connect to any computer, so I cannot even reset to factory conditions. This is ironic because the keyboardio that refuses to connect now is the same one that is supposed to serve as a backup in case of failures on the other model 100 or on the model 01, and it was just going to receive the update for the one-shot issue we were discussing above. It never connected to the computer to be updated... Anyway, I got myself a new priority. I will update the PR, and I would like some help with the administrative issues as well as creating the test for this change. I am not sure if the idle leds plug in would not do the same cleanup of all sticky keys, rendering this change somewhat redundant. Thanks for reading.

…

--Luis Nakano.

On Sat, 15 Oct 2022 at 18:10, Michael Richters ***@***.***> wrote: Apart from largely administrative issues (code style & DCO), this change is missing one crucial element: start_time_ would need to be changed from uint16_t to uint_32_t—or, perhaps preferably (I'm not sure), a different timeout mechanism should be used. On keyboards with generously-sized MCUs (e.g. Model100), using 32-bit integers is generally fine, but on the AVR boards, every little bit helps. I want to suggest storing the timeout as an integer number of seconds (or perhaps even minutes?), and keep a separate count of seconds since the last one-shot key became sticky. That comparison wouldn't need to compensate for integer overflow (unless you consider a timeout of greater than 18 hours to be reasonable, assuming the ttl and count are stored as 16-bit integers). This alternative approach might be better for the smaller MCUs, but it might just be simpler to increase the size of start_time_ and use just the one timeout-checking function. — Reply to this email directly, view it on GitHub <#1276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF7WRF7ZFZIVEXJXL5OYR23WDMTVLANCNFSM6AAAAAAREZZW2U> . You are receiving this because you authored the thread.Message ID: ***@***.***>