You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a firmware with a printable character on the default layer's prog key (or worse, a malfunctioning firmware) is installed, it can be difficult to flash a new firmware, even when starting with the keyboard unplugged. It would be easier if the keyboard stayed in the bootloader as long as the prog key is held down, so that the user doesn't have to hold down prog, plug in the keyboard, and rush to press enter while hoping the flashing starts before the keyboard's firmware starts up.
The text was updated successfully, but these errors were encountered:
I'm not a hundred percent sure how best to do this, but one way would be to change CheckProgrammingKey to set Timeout to zero when the key is held, and call this function from main. This should be minimal increase in code size, and still get the job done.
The side-effect of it, as far as I understand, is that the timeout would start when the boot key is released. That makes sense, in my opinion. On the other hand, we may want to lower the 30 second timeout in this case.
Turns out this is harder than first anticipated, because CheckProgrammingKey doesn't just return a bool. At a first read, I'm not even sure what it does.
When a firmware with a printable character on the default layer's
prog
key (or worse, a malfunctioning firmware) is installed, it can be difficult to flash a new firmware, even when starting with the keyboard unplugged. It would be easier if the keyboard stayed in the bootloader as long as theprog
key is held down, so that the user doesn't have to hold downprog
, plug in the keyboard, and rush to pressenter
while hoping the flashing starts before the keyboard's firmware starts up.The text was updated successfully, but these errors were encountered: