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

Ben Coman notifications at github.com
Wed Jun 12 16:04:00 UTC 2019

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)):

    case WM_CHAR:
    case WM_SYSCHAR:
      /* Note: VK_RETURN is recorded as virtual key ONLY */
      if(keyCode == 13) return 1;
+      charCode = keyCode;
      pressCode = EventKeyChar;
-  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:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190612/9c8e5624/attachment-0001.html>

More information about the Vm-dev mailing list