Holding down multiple modifier keys on the right half often results in no key-up events for the modifiers

@ngetal - Can you reproduce this with the stock firmware? We can figure it out either way, but if it’s a problem with the firmware we ship, it’s going to be easier to reproduce AND a more serious, higher priority issue that will get fixed a lot faster.

If you can repro it with the stock firmware, please open a GitHub issue against Kaleidoscope.

Will do on Monday. Any particular commit you would like me to use?

1 Like

The binary build would be ideal: https://github.com/keyboardio/Model01-Firmware-Builds/blob/master/v1.13-MP1-BUILD/atmega32u4_firmware.hex

this sounds like something I have also experienced while using the steno plugin where i will release keys and nothing gets registered but the keys are still being held down i submitted an issue here https://github.com/keyboardio/Kaleidoscope-Steno/issues/3 but reading this I am thinking the issue is deeper than then steno plugin. especially reading it effects you only with the right modifiers.

Thanks. Is there some help available on how to flash that? I couldn’t find anything in the wiki.

Flashing problem on Ubuntu (SOLVED) should be an ok start

1 Like

I managed to reproduce this using the firmware you linked with one difference. RightCtrl+RightShift no longer caused problems, so I changed my editor shortcuts to work off Alt+Shift - which on the default firmware are the same physical keys as described in the OP.

I now get Alt and Shift stuck consistently when doing the following:

  1. Press and hold LeftAlt and RightShift (the 2 leftmost thumb keys on the right half)
  2. Press and release T
  3. Press and release R
  4. Release LeftAlt and RightShift

I went a little further and tried this in a few other configurations:

  • Could not reproduce it using the left half of the keyboard or by holding one modifier on the left and the other on the right
  • Could not reproduce it using the buttons labeled shift and ctrl on the default arrangement on right half no matter what firmware I used
  • Reproduced it using any 2-button combination of shift, alt and space on the default arrangement on the right half
  • Reproduced it using any 2-button combination of alt, space and ctrl on the default arrangement on the right half

GH issue: https://github.com/keyboardio/Kaleidoscope/issues/239

On @algernon’s suggestion I did a few other tests, here’s what I found (copied from the GH issue):

It could very well be a hw issue. I recorded a short video demonstrating the problem: https://youtu.be/rapOiyf1OFY


  • I remapped the right thumb cluster to U I O P
  • I managed to repro the sticking by just pressing pairs of keys in the right thumb cluster
  • Contrary to my earlier tests, using any 2 keys from the right cluster at the same time can achieve this
  • When keys get stuck, I can unstuck them by pressing any of the keys on the right half, even the likes of fn. Pressing keys on the left half does not achieve this (this is not in the recording therefore)
  • The issue seems to only affect the 4 thumb keys. I haven’t yet achieved this using any other keys.

Edit: forgot to mention and it does not come across properly in the video that the right cluster tends to not recognise one or both of a pressed key pair. So out of say 10 presses of I+P as above, there would be one where neither I or P are recognised and another one where only one of them.

@jesse any idea what I could try next?

Update for anyone who might still be interested. The problem is still present and Jesse has been great helping me try to get to the bottom of it. On his suggestion I managed to reproduce the problem using the built in test mode of the keyboard on the stock firmware and I recorded two short videos showcasing the problem.


In the first one at https://youtu.be/qU01yX7-E_g I tap two of the right hand thumb keys at the same time and sometimes they get stuck in the down state after they are released.


In the second one at https://youtu.be/MmbxDY1eThI I press all 4 keys of the thumb clusters at the same time while in test mode. The left side is okay, but the right side intermittently has problems registering key downs, indicating there is something funky with that row.

For example at 0:31:

  1. press all 4 keys -> only Shift and Alt registers
  2. release Ctrl while holding Shift, Alt and Space down -> Space registers
  3. press Ctrl back -> all of them are green


Can anyone else reproduce any of these? My keyboard is an MP1, in case that matters.


I have attempted to reproduce your issue on my MP1 keyboard using the method from video 2 and I was not able to do so.

I can’t say that it isn’t common, only that it doesn’t seem to be ubiquitous.

1 Like

yes I can reproduce this, I first noticed it when using the steno plugin the right side β€˜space’ β€˜ctrl’ being held down at same time would sometimes cause the keyboard to think they were still being held down after I released them.


@buc @Kipples thanks for that.

It is still uncertain whether this is a HW or SW problem. I can consistently repro it with two different MP1 right halves, but it appears there are relatively few of us who are affected.

For what it’s worth, I’m running almost stock firmware. The only customization I’ve done so far is to remove most of the LED lighting patterns and add in one for (56, 0, 98).

Yeah, whatever this is, running the stock fw won’t solve it for those affected.

In those 2 videos I recorded I was also using the stock fw available at https://github.com/keyboardio/Model01-Firmware-Builds/blob/master/v1.22-MP2-BUILD/atmega32u4_firmware.hex

Will MP5 be held up until this problem is root caused and fixed?

Good question, so far the only reproduction I know of other than mine is @Kipples’s. That might indicate it could be isolated to a few units.

How about you? Can you repro it?

(reposted as a reply)

Since the electronics for MP5 are already done and we’ve only seen two people able to reproduce this, we’re not planning on holding MP5. (I expect this to be something that can be fixed in software)

I finally managed to repro this somewhere else: the leftmost column of the left half.

I can get pairs of keys there stuck in either the up


or down state.


Perhaps there is an off-by-one error somewhere?

FYI, @jesse said on IRC last night that he thinks he figured out the problem, and it is an occasional packet loss between the key scanner and the AVR.

1 Like

Is there any hw or sw difference that would cause that packet loss to only occur for these very specific key locations and only when 2 or more keys in those groups are pressed simultaneously? Perhaps there is some routine that’s supposed to deal with those losses but due to an error somewhere it doesn’t work for these specific columns?