[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Linux Squeak VM X11 keyboard changes breaks 32b VM (#396)

[Ben Coman]

Paraphasing http://forum.world.st/Windows-cog-vm-Keyboard-events-related-about-keycode-mapping-td4330359.html

> **guillep:**  I was playing to add Function Key support in the windows vm (yep, always the same :P), and looking at the code, I saw this in the recordKeyboardEvent:
```
  evt = (sqKeyboardEvent*) sqNextEventPut();
...
  evt->charCode = keymap[keyCode & 0xff];
```
> the problem with that line is that KeyDown and KeyUp events send VirtualKeycodes as keycodes and the Char event sends a unicode char value.  And, it makes collisions, since for example:
-- $p char value is 112 ; and 
-- F1 virtual code value is 112 too

And other keys are the same, image-side having the same keycode with different keys.
To distinguish these keys, the following provides to the image a Char event the keycode without mapping ([code link for more context](https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/aed5e3391301011cc6b9ee6a353ee563f4ab6dbd/platforms/win32/vm/sqWin32Window.c#L1319-L1337)):

```diff
    case WM_CHAR:
    case WM_SYSCHAR:
      /* Note: VK_RETURN is recorded as virtual key ONLY */
      if(keyCode == 13) return 1;
+      charCode = keyCode;
      pressCode = EventKeyChar;
     break
...
-  evt->charCode = keymap[keyCode & 0xff];
+  evt->charCode = charCode? charCode : keymap[keyCode & 0xff];
```

> **andreas:** The change makes no sense (it will break most non-ascii input like accents, umlauts, etc). You really shouldn't be using character events for handling function keys. There is no 'F11 Character' in any character encoding world-wide so trying to represent F11 as a character is completely futile. You need to use keyDown and keyUp events, since F11 & friends are KEYs not CHARACTERs.

> **guille:** Sure! I'm not generating Char events for F11 ;).  Since F11 does not generate Char events.
The problem is that the p key generates the same KeyDown event than F11 for the vm.  I'm only fixing that p-key and F1-key have different keyCodes for KeyDown and KeyUp events.  
Now, utf32Code should be only used on KeyChar events, and I don't care about them.
..
How does it work now?
(KeyDown, KeyUp) and KeyChar events send different keyCodes to the image.
Right now works because in no place in the image keyDown: is handled.
..
More on, in the unix vm, the behavior is the following:
when pressing F1:
-- key: 112 char: 112 type: keyDown
-- key: 112 char: 112 type: keyUp
when pressing p:
-- key: 112 char: 112 type: keyDown
-- key: 112 char: 112 type: keystroke
-- key: 112 char: 112 type: keyUp
when pressing shift + p (P):
-- key: 254 char: 254 type: keyDown
-- key: 80 char: 80 type: keyDown
-- key: 80 char: 80 type: keystroke
-- key: 80 char: 80 type: keyUp
After adding support for Function keys, when pressing F1:
key: 16 char: 16 type: keyDown
key: 16 char: 16 type: keyUp
..
The question is: Should KeyDown, KeyUp and KeyChar events for the same key produce the same keyCode?  I think yes.  Because the keyCode indicates the key pressed in the keyboard. Doesn't it?

> **andreas:** It does. Which is precisely the reason why it *can't* produce different values when you press the shift key with it. The KEY you are pressing does not change depending on the modifier; your OS decides that the combination of the Shift key and the P key produces an uppercase P character. 

> **guille:** The main problem is that I want keycodes to be the same through the three platforms (unix, mac and windows).  And for that, I have to do a mapping somewhere (this piece of code I wrote today was to play and see how it behaves, because the codes are to be defined :) ).
So, I thought those conversions could be done through the keymap array.
Maybe that's not the way to do the mapping, but the mapping should be done somewhere.

> **andreas:** There was general agreement that probably the best way to do this would be based on the X11/keysym.h because it seems to be the most complete source for key codes. It's just that that nobody sat down and wrote the mapping from VK_XXX to XK_YYY.

> **guillep:** Hmm, that would be good, I'll have a look tomorrow :).  Thanks!

What was the conclusion of looking at that @guillep?

 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/396#issuecomment-501341793
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190612/9c8e5624/attachment-0001.html>