Hi Pirmin,
I'm playing around with the Turmvilla scenario as Norman provides it.
great to hear that you are experimenting with the scenario!
Sometimes the keyboard input will be stuck in one of the started subsystems. Mostly this is the case with the linux subsystem (I only recognize this when I shut down linux and want to close the nit_fb), but I also had the case where it was stuck in the noux subsystem.
Is there a way to unstuck the keyboard, or a way how I could debug what happens?
I also noticed this sporadic behavior, which mystifies me quite a bit. Sometimes there is either a superficial press event (for which no release event is generated) or a release event goes missing. I notice this when using a USB HID keyboard. The problem in this situation is that nitpicker assumes that a key is kept pressing and behaves differently. For example, unless the number of pressed keys is zero (tracked by nitpicker's key_cnt variable), nitpicker won't switch the keyboard focus when clicking with the mouse.
As a workaround - just to regain control over the situation - my turmvilla branch has the commit "nitpicker: hack to reset key_cnt via F9". Each time when releasing F9, the key_cnt is hard reseted to zero. However, this is of course just a messy workaround until we find the actual problem.
Just out of curiosity, are you using a USB or PS/2 keyboard?
Cheers Norman