VICE on Debian GNU/Linux running on amd64. If I press shift it sticks. Then every character is printed as shifted while I typing. The only solution to de-shift to switch the focus to an other Xorg window and go back to x64.
*** VICE Version 2.4.7 ***
OS compiled for: Linux glibc 2.19
GUI compiled for: GTK+
CPU compiled for: AMD64/x86_64
Compiler used: GCC-4.9.1
Current OS: Linux 3.14-1-amd64 (glibc 2.19)
Current CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
[...]
X11: GTK version compiled with: 2.24 (xf86 ext:yes cairo:yes pango:yes VTE:yes hwscale:yes fullscreen:yes ui-threads:no)
XRandR: XRandR reports current display: 1280x1024@75
Loading system file /usr/lib/vice/C64/kernal'.
C64MEM: Kernal rev #3.
Loading system file/usr/lib/vice/C64/basic'.
Loading system file /usr/lib/vice/C64/chargen'.
[...]
Keyboard: Loading keymap/usr/lib/vice/C64/x11_sym.vkm'.
[...]
Main CPU: starting at ($FFFC).
Main CPU: RESET.
Sound: Opened device `pulse', speed 44100Hz, fragment size 1.5ms, buffer size 100ms
reSID: MOS6581, filter on, sampling rate 44100Hz - fast
Drive 8: RESET.
what desktop environment/window manager are you using? it works fine here on gentoo/KDE
Tried with Xfce4, KDE4 and GNOME3.x . Can't remember the last one, but it definitely fails on the former two.
Last edit: GCS 2014-09-13
Back then (in 2.4.6) tried to debug this issue. I've found out that VICE don't get the de-shift event. Other keys had a press - unpress event if I remember correctly.
Now I could find out more. It seems to relate how Xorg handle keyboard change:
If I issue setxkbmap -model logicordless -layout "us,hu(qwerty)" -option "grp:shifts_toggle" then shift sticks in x64. But if I map keyboard change to alt+shift with setxkbmap -model logicordless -layout "us,hu(qwerty)" -option "grp:alt_shift_toggle" then it works as expected.
Hmmm why do I own this ticket? If it applied to the Xaw GUI, I could understand that...
because i fucked it up =) should have been pottendo of course :)
This ticket should be marked "closed -- invalid". It isn't VICE; it was a bad X Window keyboard setting. He found the fix: -option "grp:alt_shift_toggle" (his bad setting had told the shift-keys to act like push-on-push-off light switches).
Please read me correctly. With -option "grp:shifts_toggle" all applications works correctly. Both shift keys used to switch between keyboard layouts. Simple shift threated correctly everywhere, expect VICE where it sticks.
-option "grp:alt_shift_toggle" is a workaround, not a fix.
OK. I didn't realize what that plural "shifts" means. Now, I understand.
By the way, bug ticket [#383] seems to describe the same problem.
Related
Bugs:
#383Yes, seems to be the exact same case. I got an other report where the user don't have multiple keyboard layouts set, but shift sticks there anyway. Still, the -option "grp:alt_shift_toggle" is a workarond on that machine as well.
I've Xfce4, but the mentioned user has KDE (version 4 I believe).
hmm, again trying to reproduce I failed (again).
My setup is based on Ubuntu 12.04 (shame on me) and the following details:
*** VICE Version 2.4.7, rev 28401M ***
OS compiled for: Linux glibc 2.15
GUI compiled for: GTK+
CPU compiled for: AMD64/x86_64
Compiler used: GCC-4.6.3
Current OS: Linux 3.2.0-68-generic (glibc 2.15)
Current CPU: Intel(R) Core(TM) i7 CPU 970 @ 3.20GHz
[...]
X11: GTK version compiled with: 2.24 (xf86 ext:yes cairo:yes pango:yes VTE:yes hwscale:yes fullscreen:yes ui-threads:yes)
I use gnome-shell as desktop.
I even have 3 keyboard layouts defined (en, de and ru) - I can switch between them using shift & capslock (as in windozw, I think).
So having seen the reports I'm somehow clueless how to debug this.
I'll read the code (again); maybe I see something.
sorry, pottendo
Then please try setxkbmap us,ru -option "" -option "grp:shifts_toggle" and press both shifts to change between layouts. If it works in your terminal, then start x64 for example. Type something with shift or just press it. Then see if it sticks for you.
I can help you with some debug information. When shift works, I get the following for shift:
KeyPress
65506'. KeyRelese65506'.When it sticks, I get:
KeyPress
65506'. KeyRelese65032'.So the shift keyrelease gives a different code. Don't know the reason why.
Thanx for the instructions - can reproduce the effect now.
Hmm - now I'm still clueless what to do. The relevant code is quite clear:
src/arch/unix/x11/gnome/gnomekbd.c:
[...]
case GDK_KEY_RELEASE:
if (key == KEYSYM_Shift_L || key == KEYSYM_Shift_R || key == KEYSYM_ISO_Level3_Shift) {
keyboard_key_clear();
}
[...]
so gdk reports a different code in this case - how should vice know?!
A kludge could be to hardcode the values instead of using the KEYSYM macros... ugly, IMHO.
Changing the code to:
[...]
if (key == KEYSYM_Shift_L || key == KEYSYM_Shift_R ||
key == KEYSYM_ISO_Level3_Shift ||
key == 65034 || key == 65032) {
keyboard_key_clear();
}
[...]
works.
gdk bug?!
pottendo
Committed a workaround on trunk.