#383 Odd behaviour of shift key with gnomeui3

[LGB Gábor Lénárt]

I'm using regurally freshed svn version of VICE on Linux with GnomeUI-3. But please note that this happened sometimes with gnomeui-2 too as far as I can remember. However not it seems to be a permanent problem. After starting up any of the emulators, everything seems to work perfectly. If I type and I use the shift button (even if alone without any key, but also if I use it to type a shifted symbol, I am using symbolic kbd mapping btw) then everything I type from that point remains shifted. If I position the cursor ourside of the vice window, or invoke a vice menu etc, the problem goes away though.

[gpz]

i cant reproduce this here (gtk2)

[LGB Gábor Lénárt]

Neither me with gtk2, it seems it's a gtk3 thing (--enable-gnomeui3)?

[pottendo]

Hi, tried to reproduce with a gnome3 build, but failed.

You may try to activate the debug macros in
src/arch/unix/x11/gnome/gnomekbd.c
by uncommenting:
#define DEBUG_X11UI
#define DEBUG_KBD

and check assymetry of key-press and key-release events.
The menu access sets back certain flags and therefore can fix some missed events.
This may be system performance related - my machine is fast, so all events are processed properly. But I assume X11 events can be missed in some rare cases.

Anyway, the current gnome3 support is not recommended as the GL bindings aren't there, which kills some nice feaures like GL blending, etc.

pottendo

[LGB Gábor Lénárt]

That's odd, and I found something very interesting. For fun, I'm writing an emulator for a Z80 based computer in JavaScript running inside the browser. And I have exactly the same problem as this bug report, shift "stucked"! Interestingly only one machine of mine, other programs (text editors, terminal emulators, etc) seems not to be affected at all! I guess it's an interesting information as the key handler of JS code is very different from native app VICE, but still the same problem. If it helps, I can say, that what can I see in Javascript is that releasing the shift generates a 0 keycode, instead of generating keycode 16 as being released. I think it's somehow related to my desktop/X11/gnome/unity/etc settings on that single machine but I can't tell what it can be, so "average" applications are not bothered just some of them, like VICE.

Btw, I've tried xev to grab X11 events, and on the problematic machine I can see this while pressing then releasing (left) shift key:

KeyPress event, serial 41, synthetic NO, window 0x4200001,
root 0x98, subw 0x0, time 2300931, (578,265), root:(1303,317),
state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x4200001,
root 0x98, subw 0x0, time 2300979, (578,265), root:(1303,317),
state 0x11, keycode 50 (keysym 0xfe0a, ISO_Prev_Group), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

I have no idea what "ISO_Prev_Group" is, I can't see such a thing if I try the same on another machine with xev. The only difference between these machines that the problematic one is a notebook, while the other machine is a generic no-name desktop PC. xev output fragment on the "good" machine:

KeyPress event, serial 38, synthetic NO, window 0x5000001,
root 0xa5, subw 0x0, time 488655016, (-75,-52), root:(730,0),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x5000001,
root 0xa5, subw 0x0, time 488655220, (-75,-52), root:(730,0),
state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

So it seems KeyRelease event not even generated for Shift_L, huh? Sorry guys, after all of these, I can say, it can't be a vice bug, but X, or something other on that machine of mine. Sorry for wasting your time, and thanks for the time on my report.

[LGB Gábor Lénárt]

Btw, I did an ugly workaround in my JS emulator to avoid this issue: I reset the emulated keyboard matrix (no any key is pressed) if I got keycode zero in keydown JS event. But I am not sure it's worth to mess up VICE's codebase just to cure a problem which seems to be only found on one machine of a single person (me) :) Now thinking on the issue, it's possible that multiple keyboard changer option can cause this, at least that ISO_Prev_Group made me think on that? Hard to explain how this is problematic if other applications do not suffer with stucked shift key only some ...

[pottendo]

Committed a workaround on trunk.