#1199 strange keyboard (CTRL & CBM) behaviour

[Querino]

• start x64sc (windowed)
• press key which is set to CBM in emu and keep pressed
• move mouse pointerto some other app
• click this app to get focus, remember CBM still pressed
• now release CBM
• switch back to x64sc

now the CBM key is still pressed in the emu. the same procedure works also with CTRL.

obviously the emulator can not detect that we released CBM while we were "away".
pressing/releasing CBM now again releases.

but i can also set some other key to CTRL or CBM
xxxxx 7 2 16384 / xxxxxxxxxxxxxx -> ctrl /
or
xxxxx 7 5 8192 / xxxxxxxxxxxxxx -> cbm /
now that key does behave the same way.

my guess is this happend with

https://sourceforge.net/p/vice-emu/code/36791/

i had a look at this, sadly my skills are way too limited.

i hear you: who cares, edge case. but i wonder if it can be fixed? and how?

[gpz]

sounds like an issue that probably existed before that commit....

perhaps the solution is to simply make the emu release all keys when the mousepointer is moved outside the emulator window?

[Greg King]

It's not a bug; it's the normal way that GTK/GDK works. It's based on the way that X11 (X Window System) works. When an input condition changes, an "event" (announcement) is given to the currently active window. Typical events are "Left Shift pressed", "Left Shift released", "Space pressed", and "Space released". GDK/GTK sees those announcements, and remembers what it thinks is the current condition of some inputs. VICE does the same thing with mapped keys. (They don't ask the keyboard, "what is your current state". They think that they know it.)

Therefore, if you press a key while VICE's window is "current", click a different window, and raise your finger, then VICE sees only the "key pressed" announcement. It doesn't know about your second finger movement -- VICE thinks that the key still is down!

The space bar gives a simple, visible demonstration:
Launch any GTK3VICE emulator. Make its window "single size". Launch another program (a good choice is something that ignores the space bar -- I used Windows' File Explorer). Make the two windows not overlap each other. Click on VICE. Tap <Home>. Hold down the space bar -- the cursor will "fly" across the window. Click on the other window (I needed to click my secondary button because an active keyboard blocks my primary button). Release the space bar. VICE's cursor will continue to fly. Click on VICE's emulation screen. That window will be active, and you won't be touching the space bar; but, the cursor still will move!

[Querino]

greg, i think your example is different.
the space bar stops acting when going back to VICE. even if you just hover the mouse over VICE. in my example, the key is completely stuck.

also the issue i described did NOT happen on versions before mentioned commit, just check stable GTK3 v3.2. yours indeed is present there too.

perhaps the solution is to simply make the emu release all keys when the mousepointer is moved outside the emulator window?

the situation is worse. you can also set some global hotkey like CTRL+SHIFT+E (which activates/loads some other app) and press that if VICE has focus, and when you go back to VICE, the key is locked.

as soon as you have a key pressed that is defined as CTRL or CBM (flag 16384 or 8192) and VICE loses focus, the key is locked in VICE.
in theory, it could be any key on the host keyboard, but usually on the HOST CTRL we have either CTRL or CBM.

[Greg King]

greg, i think your example is different.
the space bar stops acting when going back to VICE. even if you just hover the mouse over VICE.

That happens only if you do something that sends an event. For example, tapping a key, or hovering over a status-bar region that changes the mouse cursor's shape. The only difference between our examples is that fewer events are able to cancel state-modifier keypresses.

also, the issue i described did NOT happen on versions before mentioned commit, just check stable GTK3 v3.2. yours indeed is present there too.

I typed:

GDK/GTK sees those announcements, and remembers what it thinks is the current condition of some inputs. VICE does the same thing with mapped keys.

The revision that you cited added the ability to remember CBM and CONTROL.

[compyx]

This appears to me to be normal GDK behaviour, once you "unfocus" a GDK Window no events will pass to it until you "refocus".

So I'd write this off as "works as expected from a toolkit standpoint, but perhaps not from a user standpoint".

[Querino]

ok, got it, thanks guys.

[gpz]

mmmh how should we handle this? is this a rare case of "wont fix"? :)

[compyx]

Yes. Even if we could implement some weird "keyboard grab", I doubt many window managers will allow it.

[Greg King]

This patch clears the keyboard (on Windows, at least) when VICE loses the keyboard focus.

[gpz]

please post patches where they belong, on the patches tracker - only that makes sure we will not forget about them

[gpz]

can we close this? it should work now :)

[Querino]

ok.

[compyx]

OK.

[gpz]

closing :)