#1519 Keymap issues with shift, ctrl, cbm

[(>Gate Keeper<)]

Tested using vice-gtk3-3.5-r39878.dmg and current stable 3.5 dmg (which is not as recent).

OS is macOS 11.5

SUT is a recent model Intel Macbook Pro.

Macbook Pro Keyboard Setup: System Preferences -> Keyboard -> Input Sources ... Set to U.S. Also tried "ABC" and "U.S. International - PC" and neither helped.

Using gtk3_sym.vkm standard mapping file (from stable 3.5 installation).

Steps to reproduce:

1) From BASIC, run code:

10 PRINT PEEK(197)
20 RUN

2) Press [LEFT SHIFT] + Z, scancode returned is 55 (incorrect - this is scancode for "?")
3) Press [RIGHT SHIFT] + Z, scancode returned is 12 (correct)

This appears to be the only key I must use right shift in order to get the correct shifted character.

[dqh]

I've confirmed this on Windows as well as mac.

[Strobe]

SDL2 is fine. Keymaps look OK for both Z and "?". GTK3 only issue it seems.

[(>Gate Keeper<)]

Looking at the keyboard scan row/cols - this problem would manifest if Right Shift+Left Shift+Z was pressed which would cause the "triangle" pattern where a 4th key would "pop out". In this case, the 4th key would be "/" which is unshifted "?".

It seems, therefore, the issue is that when a Left Shift is pressed, the emulator in its current configuration also presses right shift.

Scan Ref	ColBit0	C.B1	C.B2	C.B3	C.B4	C.B5	C.B6	C.B7
Rw Bit 1:	3	W	A	4	Z	S	E	LShft
Bit 6:	£(pound)	*	;	Clr/Hm	RShft	=	↑	/

Where Z + LShft (Left Shift) + Rshft would "pop out" the "/" since it's under LShft.

That's normal. It's unexpected that pressing Left-Shift on the emulator's host system would cause this "triangle" behavior with only two keys pressed so my assumption is that Left shift is also causing a right shift to be pressed.

[(>Gate Keeper<)]

I do not think this is limited to "Z" so the description is currently not appropriately scoped.

It appears GTK3's left shift will also generate a right-shift when nearly any key pressed.

20 POKE 53295,255
30 POKE 56320,191
35 A=PEEK(56321)
36 IF A=255 GOTO 50
40 PRINT A”(239=RSHFT)”;
45 IF (A AND 16)=0 THEN PRINT “R-SHIFT DETECTED”;
46 PRINT
50 POKE 56320,253
60 B=PEEK(56321)
70 IF B=255 GOTO 30
80 PRINT B”(127=LSHFT)”;
85 IF (B AND 128)=0 THEN PRINT “L-SHIFT DETECTED”;
86 PRINT
90 GOTO 30

Pressing left shift and almost any other key (qwertyuiop,asdfghjkl,zxcvbnm) -- and more show the right-shift scan result although only the left shift was pressed.

Left shift by itself does not generate a right shift as was an original hypothesis. However, nearly any other key does generate the right shift when the left shift is pressed.

This is why I say relating to "Z" is too limited a scope. It's easiest to see the LSHFT+Z issue but issues exist with many more keys.

[Strobe]

Think it's fixed in r40541, please test.

[(>Gate Keeper<)]

Momentarily - I have not yet built Vice from source as previously I've relied on experimental build .dmg releases. If someone wants to build and place an r40541 dmg in files - that would be appreciated. Otherwise, I'll dust off my toolchain/env and get it done in a few days.

[gpz]

you could also just grab the keymap and drop it into your vice directory

[Greg King]

Nope! It's a workaround, not a fix. That workaround would be needed in EVERY keymap in VICE.

The bug is that the virtual shift key is "pressed" even when it isn't needed (and not wanted).

That bug is known. It's mentioned in https://sourceforge.net/p/vice-emu/bugs/1187/#4059
That comment has a very useful C64 keyboard test program attached to it. It shows the bug vividly.

Run it. If you have a US host keyboard, then press the apostrophe key. The virtual (right) shift key will be pressed. Release. Then, hold down the left-shift key, and press the quotation mark. Again, the right-shift key will be pressed -- even though the left-shift already is pressed. Two shift keys will be pressed, which isn't an accurate emulation.

It happens on all three UIs.

We need the virtual shift to be disabled while any "real" shift is active.

[(>Gate Keeper<)]

I didn't crack open the commit diff to see this was just a keymap. A keymap hack (if only for SHIFT-Z) is not going to be satisfactory. I am aware of the ability to wack-a-mole sidestep SHIFT+Z. However, that is yet one of many symptoms of the underlying bug. I mention SHIFT+Z out of ease to test. The code here - and I suppose #4059 (wasn't aware of this - I searched and didn't find it) will show many other errant cases.

Still, thanks for the efforts to assist.

... as an edit - I have now circled back after reading #4059 and see that perhaps keymaps (or keymap handling) can impact the general interpretation of shift - so I don't want to yet make a blanket statement about keymaps having no value for this citing. I need to look at what's been provided more closely before jumping to any conclusions.

I'll just look at the keymap changes and import them if I think it's a reasonable approach.

[(>Gate Keeper<)]

Keymap "fix" doesn't address LSHFT+ 1|3|4|5|7|9|0|"|?|>|<
(Where "|" is "or")

There's a more root-cause method that should be employed.

[(>Gate Keeper<)]

Digging in, I see the issue is related to VSHIFT.

When you press a left-shift (and using the gtk3_sym.vkm standard mapping) - I see that VSHIFT is "down" (VSHIFT down set to 1). With the standard mapping, VSHIFT is set to virtually press the right shift key. This is where we get into trouble.

Left physical shift + Z = Left Physical + Right Virtual + Z = "?" output. This is but one example of issues related to the combination of underlying logic plus keyboard mapping.

I've helped the situation by commenting out the .vkm line "!VSHIFT RSHIFT". However, I'm not sold this is sufficient as a fix. I'd need to dig out my original C64 to make sure various key combinations are emulated correctly.

Greg mentioned this VSHIFT phenomena before. Without digging into the code, I didn't quite understand the comment as it took me some time to get the source up to start debugging here. That is what's causing the wrong scan output for certain keypresses.

[Greg King]

Virtual shift is needed for typing the apostrophe, on US keyboards.

[(>Gate Keeper<)]

Seems to be better by qualifying vshift:

static void keyboard_key_shift(void)
{
   // Adding check for physical shift already pressed
    int physical_shift = (lshift_defined() && (left_shift_down > 0))
        || (rshift_defined() && (right_shift_down > 0));

    if (lshift_defined()) {
        if (left_shift_down > 0
            || (virtual_shift_down > 0 && vshift == KEY_LSHIFT && !physical_shift) // Add check here
            || (keyboard_shiftlock > 0 && shiftl == KEY_LSHIFT)) {
            keyboard_set_latch_keyarr(kbd_lshiftrow, kbd_lshiftcol, 1);
        }
    }
    if (rshift_defined()) {
        if (right_shift_down > 0
            || (virtual_shift_down > 0 && vshift == KEY_RSHIFT && !physical_shift) // And here
            || (keyboard_shiftlock > 0 && shiftl == KEY_RSHIFT)) {
            keyboard_set_latch_keyarr(kbd_rshiftrow, kbd_rshiftcol, 1);
        }
    }

This doesn't address interaction with shift lock (which has broken behavior regardless) but ignoring shift lock seems to work.

The thought here is that if a physical shift is already detected, don't "press" (add) virtual shift.

... and again catching up to realizing the wisdom Greg already communicated prior.

[gpz]

This doesnt fix it, unfortunately... eg using german keymap press and hold "<", then press right shift, and release it. see what happens in "anykey". i think the logic needs to handle left and right shift seperately, must also consider unshifting, and also release shift as needed.

[gpz]

improved the logic a bit in r40654 - please test again

[(>Gate Keeper<)]

Seems like it works OK. Compiled with "./configure --enable-native-gtk3ui" and reverted the gtk3_sym.vkm someone checked in as a work-around. Works "the same" for what I was able to test with the non-differentiated version. No German kbd here to test although logic would seem to use the physical shift (left or right) in the other version masking all virtual shifts. Which seems to end up in the same place - but I yield to the wisdom of those with more history with the project.

I'd probably suggest backing out the vkm "hack" (r40541) unless there's independent value in it.

Kbd emulation isn't perfect - but I believe the major problems resulting from vshift+physical shifts are cleared out. Limited testing has positive results.

[gpz]

please try again with r40678, which solves some more problems. the new keymaps are now absolutely required.

[(>Gate Keeper<)]

Testing with r40678 (w/bundled gtk3_sym.vkm) seems to work OK. I notice that key auto-repeat works differently now. I don't have a reference system to see how it should - but it seems OK. Before keys didn't repeat when held.

Caps lock (shift lock) still doesn't work right. It working or not was not a consequence or related to the original issue. The new debug information doesn't track shift lock. I'm not sure this issue should morph to track caps lock - but just following the "solves more problems" possibilities. I think most of the issues associated with the original problem (regular shift related) are OK (or at least better).

I do wonder how one presses shift + PLUS to generate the "big +" symbol that would result on a C64. Along the way of fixes - there was a time when I could make a "Shift +" (this is referencing a C64, not the host keyboard) would work and display the "big plus". It wasn't consistent - but I could sometimes make it happen. Now it seems I can't get this out. This would go for any key that C64 has as non-shifted but a PC maps as shifted (and where that same key on the C64 has some special meaning when this normally not-shifted key adds a shift key).

... back to "real" testing - modifier keys don't seem to work for 0-9. I'm trying to change the color of the cursor in basic and that doesn't seem to work anymore.

Seems Ctrl+numbers or C=+numbers no longer work to change colors.

[gpz]

At this point you should tell exactly:

• what GUI are you using (SDL or GTK)
• what OS are you using
• what keymap is active (see the log file)
• what is your host keyboard layout
• it would be super helpful if you'd enable "keyboard status in status bar" and tell exactly what it shows for the keys that do not work right for you

we may very well be looking at another problem with GTK itself here rather than an actual problem with the keymapping, so we need to look at the whole chain

that said, the "symbolic" keymap is active by default - using this keymap you will not be able to produce all keys, you'll have to use a positional keymap. and even with this, some things can not work (due to lack of individual keys).

shift-lock is an entire beast to deal with by itself, and by principle can not work 100% exactly like on c64 either, at least not when mapped to the actual host caps-lock. different host OSs handle this differently too, which only adds on top of the mess.

[(>Gate Keeper<)]

GTK3
MacOS
gtk3_sym.vmk
US

---

*** VICE Version 3.5, rev 40678 ***

Welcome to x64sc, the free portable C64 Emulator.
...
using GTK3 backend: OpenGL
...

% sw_vers
ProductName: macOS
ProductVersion: 11.5.2
BuildVersion: 20G95
...
Keyboard: Loading keymap `/Users/myusername/Vice_Src_r40678/trunk/vice/data/C64/gtk3_sym.vkm'.
...

read /Library/Preferences/com.apple.HIToolbox.plist AppleEnabledInputSources
(
{
InputSourceKind = "Keyboard Layout";
"KeyboardLayout ID" = 0;
"KeyboardLayout Name" = "U.S.";
}
)

Note that previous nightly was better with respect to ctrl+C= keys interacting w/numbers 0-9.

"Enable keyboard debugging on statusbar" output:

(Each preceded by "KBD debug: "
Ctrl+0 = "48, 0x0030 0 --C -----"
Ctrl+1 = "49, 0x0031 1 --C -----"
Ctrl+2 = "50, 0x0032 2 --C -----"
... and so on (50 increases by 1, 0x0032 inc by 1, "2" inc by 1 ... through:
Ctrl+9 = "57, 0x0039 9 --C -----"

The screen output (x64sc resulting interpretation) is to print out "0123456789" when pressing Ctrl+numbers0-9. Apparently now not seeing the ctrl.

"Enable keyboard debugging on statusbar" output:
(Each preceded by "KBD debug: "
C=(tab on my keyboard)+0 = "48, 0x0030 0 --- -----"
C=+1 = "49, 0x0031 1 --- -----"
C=+2 = "50, 0x0032 2 --- -----"
... and so on through:
C=+9 = "57, 0x0039 9 --- -----"

And again on the screen I see the output of "0123456789" instead of the special keyboard characters when the C= is held.

[(>Gate Keeper<)]

... it's worth mentioning that lately dmg images for the keyboard fixes haven't been supplied so I started compiling my own from source. This is new (my Vice compile setup) and may possibly be a source of skewed results. After compiling in order to test, I take src/x64sc and copy it to data/x64sc then run data/x64sc

[gpz]

you dont see a line like
65507, 0xffe3 Control_L --- -2---
when pressing Control (or whatever control is mapped to on macOS)?