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?
I have no more information other than the above. I’m sure @jesse will explain things in due time.
I just wanted to let you know that there is progress being made =)
1 Like
I… don’t think so. But it’s not outside the realm of possibility.
The best I’ve got so far is that the problem is somewhere between the code that scans the hardware on the ATTiny and the code that updates the keymap state on the ATMega. Because it’s reproducible in the test mode, that means it’s not anywhere in the USB stack, a plugin or handleKeyEvent.
My money is on either something related to the ringbuffer on the attiny or something related to our i2c communications between the atmega and the attinys.
1 Like
I was just now able to reproduce this on my second keyboard, but I still can’t on my first keyboard. Perhaps the cause is more on the hardware layer?
Edit: My second keyboard is from MP2.
1 Like
Thank you. Is that also an MP1?
Just noticed this thread and chiming in FWIW that I also experienced the same issue with the right thumb key modifiers. It doesn’t happen frequently enough to bother me yet (or maybe I just don’t press those keys very often).
I have yet to check in test mode, but leaving the “burning trail” LED effect on really helps as a debugging tool to identify keys that misbehave sporadically during normal use. I set it to the default when I suspect a problem so I can confirm that I’m not losing my mind after I see the right ctrl and shift stuck glowing every now and then 
3 Likes
Thanks for that. Any chance you could check it with test mode and also on the prog-pgdn column?
(Also why am I unable to reply to a specific post in a thread? - edit: seemed to work this time)
I just played around with these keys in test mode for a few minutes and I could not get the issue to appear on the right thumb keys or on pgup and pgdn during that time.
I’m certain that I saw it before, though, with the right thumb keys at least. As described above, I noticed the problem because the LEDs behind those keys remained illuminated after releasing them (stalker effect), and I could trigger application-specific actions bound to other keys with those modifiers without pressing the keys down again. I witnessed the issue via the stalker effect twice now (and unintentionally a couple times before that), but it seems to occur very infrequently on my keyboard, and I don’t press those keys together often.
The Discourse forums software we use here doesn’t show an explicit reference when someone replies to a message that immediately precedes the reply (like when posting a reply to the last message in the thread).
1 Like
I finally managed to reproduce this with a test board hooked up to a logic analyzer.
The failure happens when exactly two keys in the first column of the board change state during the exact same keyscan cycle. (On the left side, the Prog column is the first column. On the right side, the thumb keys is the first column.)
When this happens, the keyscanner firmware, for some reason, does not send a key state change event to the main controller.
The problem becomes much easier to replicate consistently when I only scan the key matrix once every 5 seconds.
At this point, I’m confident that:
- The keyswitches are sending the right electrical signals to the ATTiny
- Kaleidoscope is doing exactly what it’s told to by the ATTiny
This tells me that the problem is -somewhere- in the avr_keyscanner firmware.
I don’t yet know -why- this is happening or exactly which codepath is causing the problem.
That’s next.
5 Likes
GOT IT!
We have a bit of guard code that will only add key changes to the output buffer if we’ve detected any debounced changes since the last cycle.
I was treating that code as a counter of how many changes we had seen in this update. But it wasn’t a counter. It was an eight bit bitmask.
So, when there were debounced changes to the most significant[1] bit of exactly two rows, we had an integer overflow issue and it reported out as ‘no changes’ instead of ‘two changes’.
@ngetal - I’ll have a new firmware for you to try sometime tonight.
[1] For physical layout reasons, the column numbers are the opposite of the physical on-board layout. So column 0 is actually bit 7 in the bitmask.
8 Likes
@jesse’s fix works flawlessly, I can no longer reproduce any of the issues mentioned in this thread with the new firmware. I’ll let him share the details just in case he has any more coding to do before releasing it to the public.
2 Likes
has this fix made its way into the repo yet? I would like to try it out.
Yup. It’s in the configurable-keyscanners-and-debouncers branch of avr_keyscanner. When you build that, it’ll also build a flashing tool.
currently trying to flash it getting an error avrdude: Error: Could not find USBtiny device (0x1781/0xc9f) is there something I am missing?