[Windows cog vm] [Keyboard events related] about keycode mapping

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[Windows cog vm] [Keyboard events related] about keycode mapping

Guillermo Polito
 
Hi!

I was playing to add Function Ket 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->type = EventTypeKeyboard;
  evt->timeStamp = msg->time;
  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 :P


And so with other keys, having the same keycode in the image side with different keys...

I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:

...
    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->timeStamp = msg->time;
  evt->charCode = charCode? charCode : keymap[keyCode & 0xff];
  evt->pressCode = pressCode;
...

changing only the bold lines, and It seems to work.

What do you think?
Guille
Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Andreas.Raab
 
On 1/26/2012 14:52, Guillermo Polito wrote:
 


Hi!

I was playing to add Function Ket 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->type = EventTypeKeyboard;
  evt->timeStamp = msg->time;
  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 :P


And so with other keys, having the same keycode in the image side with different keys...

I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:

...
    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->timeStamp = msg->time;
  evt->charCode = charCode? charCode : keymap[keyCode & 0xff];
  evt->pressCode = pressCode;
...

changing only the bold lines, and It seems to work.

What do you think?

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.

Cheers,
  - Andreas


Guille
Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Guillermo Polito
 
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:

KeyDown and KeyUp events for p key and F1 keys have different keyCodes.  I'm not sure if there will still be collisions, but right now, they are with the code as it is.

Guille

On Thu, Jan 26, 2012 at 11:02 AM, Andreas Raab <[hidden email]> wrote:
 
On 1/26/2012 14:52, Guillermo Polito wrote:
 


Hi!

I was playing to add Function Ket 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->type = EventTypeKeyboard;
  evt->timeStamp = msg->time;
  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 :P


And so with other keys, having the same keycode in the image side with different keys...

I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:

...
    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->timeStamp = msg->time;
  evt->charCode = charCode? charCode : keymap[keyCode & 0xff];
  evt->pressCode = pressCode;
...

changing only the bold lines, and It seems to work.

What do you think?

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.

Cheers,
  - Andreas


Guille


Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Guillermo Polito
 
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?

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.

Ok, right now works because in no place in the image keyDown: is handled, but that's no excuse :).

Regards,
Guille

On Thu, Jan 26, 2012 at 11:17 AM, Guillermo Polito <[hidden email]> wrote:
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:

KeyDown and KeyUp events for p key and F1 keys have different keyCodes.  I'm not sure if there will still be collisions, but right now, they are with the code as it is.

Guille

On Thu, Jan 26, 2012 at 11:02 AM, Andreas Raab <[hidden email]> wrote:
 
On 1/26/2012 14:52, Guillermo Polito wrote:
 


Hi!

I was playing to add Function Ket 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->type = EventTypeKeyboard;
  evt->timeStamp = msg->time;
  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 :P


And so with other keys, having the same keycode in the image side with different keys...

I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:

...
    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->timeStamp = msg->time;
  evt->charCode = charCode? charCode : keymap[keyCode & 0xff];
  evt->pressCode = pressCode;
...

changing only the bold lines, and It seems to work.

What do you think?

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.

Cheers,
  - Andreas


Guille



Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Guillermo Polito
 
More on, in the unix vm, the behavior is the following:

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


F1, after adding support for Function keys,
key: 16 char: 16 type: keyDown
key: 16 char: 16 type: keyUp

While in the windows vm:

when pressing p (the problematic one):

key: 80 char: 80 type: keyDown
key: 112 char: 112 type: keystroke
key: 80 char: 80 type: keyUp

when pressing shift + p (P) works the same, since P char value is the same as P virtual key value:

key: 16 char: 16 type: keyDown
key: 80 char: 80 type: keyDown
key: 80 char: 80 type: keystroke
key: 80 char: 80 type: keyUp


F1, without touching the code, shares the same keycode than p:

key: 112 char: 112 type: keyDown
key: 112 char: 112 type: keyUp

Guille

On Thu, Jan 26, 2012 at 11:43 AM, Guillermo Polito <[hidden email]> wrote:
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?

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.

Ok, right now works because in no place in the image keyDown: is handled, but that's no excuse :).

Regards,
Guille

On Thu, Jan 26, 2012 at 11:17 AM, Guillermo Polito <[hidden email]> wrote:
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:

KeyDown and KeyUp events for p key and F1 keys have different keyCodes.  I'm not sure if there will still be collisions, but right now, they are with the code as it is.

Guille

On Thu, Jan 26, 2012 at 11:02 AM, Andreas Raab <[hidden email]> wrote:
 
On 1/26/2012 14:52, Guillermo Polito wrote:
 


Hi!

I was playing to add Function Ket 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->type = EventTypeKeyboard;
  evt->timeStamp = msg->time;
  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 :P


And so with other keys, having the same keycode in the image side with different keys...

I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:

...
    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->timeStamp = msg->time;
  evt->charCode = charCode? charCode : keymap[keyCode & 0xff];
  evt->pressCode = pressCode;
...

changing only the bold lines, and It seems to work.

What do you think?

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.

Cheers,
  - Andreas


Guille




Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Guillermo Polito
 
turning the function into something like the one I paste below gives me the following output in windows:

for p key:

key: 112 char: 112 type: keyDown
key: 112 char: 112 type: keystroke
key: 112 char: 112 type: keyUp

for shift + p key (being character 16 the shift key, since it is the keycode in the platform, still different from the one in unix ¬¬):

key: 16 char: 16 type: keyDown
key: 80 char: 80 type: keyDown
key: 80 char: 80 type: keystroke
key: 80 char: 80 type: keyUp
key: 16 char: 16 type: keyUp

Regards,
Guille

int recordKeyboardEvent(MSG *msg) {
  sqKeyboardEvent *evt;
  int alt, shift, ctrl;
  int keyCode, virtCode, pressCode;

  if(!msg) return 0;

  alt = GetKeyState(VK_MENU) & 0x8000;
  shift = (GetKeyState(VK_SHIFT) & 0x8000);
  ctrl = GetKeyState(VK_CONTROL) & 0x8000;
  /* now the key code */
  virtCode = mapVirtualKey(msg->wParam);
  keyCode = msg->wParam;
  /* press code must differentiate */
  switch(msg->message) {
    case WM_KEYDOWN:
    case WM_SYSKEYDOWN:
      if(virtCode){
keyCode = virtCode;
      }else if(!shift && keyCode >= 0x41 && keyCode <= 0x5A){
 //If shift is not set and is a character we lowercase it
 keyCode = keyCode + 32;
 }else{
 keyCode = keymap[keyCode & 0xff];
 }
pressCode = EventKeyDown;
      /* filter out repeated meta keys */
      if(msg->lParam & 0x40000000) {
/* Bit 30 signifies the previous key state. */
if(msg->wParam == VK_SHIFT ||
  msg->wParam == VK_CONTROL ||
  msg->wParam == VK_MENU) {
 /* okay, it's a meta-key */
 return 1;
}
      }
      break;
    case WM_KEYUP:
    case WM_SYSKEYUP:
      if(virtCode){
keyCode = virtCode;
      }else if(!shift && keyCode >= 0x41 && keyCode <= 0x5A){
 //If shift is not set and is a character we lowercase it
 keyCode = keyCode + 32;
 }else{
 keyCode = keymap[keyCode & 0xff];
 }
      pressCode = EventKeyUp;
      break;
    case WM_CHAR:
    case WM_SYSCHAR:
      /* Note: VK_RETURN is recorded as virtual key ONLY */
      if(keyCode == 13) return 1;
      pressCode = EventKeyChar;
      break;
    default:
      pressCode = EventKeyChar;
  }
  /* remove Ctrl+Alt codes for international keyboards */
  if(ctrl && alt) {
    ctrl = 0;
    alt = 0;
  }
  
  /* first the basics */
  evt = (sqKeyboardEvent*) sqNextEventPut();
  evt->type = EventTypeKeyboard;
  evt->timeStamp = msg->time;
  evt->charCode = keyCode;
  evt->pressCode = pressCode;
  evt->modifiers = 0;
  evt->modifiers |= alt ? CommandKeyBit : 0;
  evt->modifiers |= shift ? ShiftKeyBit : 0;
  evt->modifiers |= ctrl ? CtrlKeyBit : 0;
  evt->windowIndex = msg->hwnd == stWindow ? 0 : (int) msg->hwnd;
  evt->utf32Code = keyCode;
  /* clean up reserved */
  evt->reserved1 = 0;
  /* note: several keys are not reported as character events;
     most noticably the mapped virtual keys. For those we
     generate extra character events here */
  if(pressCode == EventKeyDown && virtCode != 0) {
    /* generate extra character event */
    sqKeyboardEvent *extra = (sqKeyboardEvent*)sqNextEventPut();
    *extra = *evt;
    extra->pressCode = EventKeyChar;
  }
  return 1;
}

On Thu, Jan 26, 2012 at 12:07 PM, Guillermo Polito <[hidden email]> wrote:
More on, in the unix vm, the behavior is the following:

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


F1, after adding support for Function keys,
key: 16 char: 16 type: keyDown
key: 16 char: 16 type: keyUp

While in the windows vm:

when pressing p (the problematic one):

key: 80 char: 80 type: keyDown
key: 112 char: 112 type: keystroke
key: 80 char: 80 type: keyUp

when pressing shift + p (P) works the same, since P char value is the same as P virtual key value:

key: 16 char: 16 type: keyDown
key: 80 char: 80 type: keyDown
key: 80 char: 80 type: keystroke
key: 80 char: 80 type: keyUp


F1, without touching the code, shares the same keycode than p:

key: 112 char: 112 type: keyDown
key: 112 char: 112 type: keyUp

Guille


On Thu, Jan 26, 2012 at 11:43 AM, Guillermo Polito <[hidden email]> wrote:
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?

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.

Ok, right now works because in no place in the image keyDown: is handled, but that's no excuse :).

Regards,
Guille

On Thu, Jan 26, 2012 at 11:17 AM, Guillermo Polito <[hidden email]> wrote:
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:

KeyDown and KeyUp events for p key and F1 keys have different keyCodes.  I'm not sure if there will still be collisions, but right now, they are with the code as it is.

Guille

On Thu, Jan 26, 2012 at 11:02 AM, Andreas Raab <[hidden email]> wrote:
 
On 1/26/2012 14:52, Guillermo Polito wrote:
 


Hi!

I was playing to add Function Ket 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->type = EventTypeKeyboard;
  evt->timeStamp = msg->time;
  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 :P


And so with other keys, having the same keycode in the image side with different keys...

I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:

...
    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->timeStamp = msg->time;
  evt->charCode = charCode? charCode : keymap[keyCode & 0xff];
  evt->pressCode = pressCode;
...

changing only the bold lines, and It seems to work.

What do you think?

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.

Cheers,
  - Andreas


Guille





Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Igor Stasenko
 
Guillermo,
please make the functional keys working on windows. thanks :)


--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Andreas.Raab
In reply to this post by Guillermo Polito
 


On 1/26/2012 15:43, Guillermo Polito wrote:
 


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?

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. Similarly to the OS deciding that (when using dead keys for example) pressing the accent key followed by the a key produces an accented a. Would you expect the keyDown value for the accented a to change as well? This way lies complete madness.

Maybe you don't understand what these events are used for. Consider you are writing a game and you're using shift and control key for primary and secondary weapon action. Would you expect that the person writing the game needs to handle all of the various control and shift key combos in order to find out that the user pressed the a key to move forward?

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.

Which is exactly the right thing to do.

Cheers,
  - Andreas


Ok, right now works because in no place in the image keyDown: is handled, but that's no excuse :).

Regards,
Guille

On Thu, Jan 26, 2012 at 11:17 AM, Guillermo Polito <[hidden email]> wrote:
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:

KeyDown and KeyUp events for p key and F1 keys have different keyCodes.  I'm not sure if there will still be collisions, but right now, they are with the code as it is.

Guille

On Thu, Jan 26, 2012 at 11:02 AM, Andreas Raab <[hidden email]> wrote:
 
On 1/26/2012 14:52, Guillermo Polito wrote:
 


Hi!

I was playing to add Function Ket 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->type = EventTypeKeyboard;
  evt->timeStamp = msg->time;
  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 :P


And so with other keys, having the same keycode in the image side with different keys...

I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:

...
    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->timeStamp = msg->time;
  evt->charCode = charCode? charCode : keymap[keyCode & 0xff];
  evt->pressCode = pressCode;
...

changing only the bold lines, and It seems to work.

What do you think?

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.

Cheers,
  - Andreas


Guille



Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Andreas.Raab
In reply to this post by Igor Stasenko
 
On 1/26/2012 17:00, Igor Stasenko wrote:
>
> Guillermo,
> please make the functional keys working on windows. thanks :)

The function keys work perfectly fine on Windows. You need to handle the
keyDown events with the proper VK_FXX values, ranging from 0x70 (F1)
through 0x87 (F24).

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Andreas.Raab
 
On 1/26/2012 20:45, Andreas Raab wrote:

On 1/26/2012 17:00, Igor Stasenko wrote:

Guillermo,
please make the functional keys working on windows. thanks :)

The function keys work perfectly fine on Windows. You need to handle the keyDown events with the proper VK_FXX values, ranging from 0x70 (F1) through 0x87 (F24).

Oh, and just realizing: If you want the F2 key you'll have to disable the VM's F2 handling.
See http://squeakvm.org/win32/settings.html

  • EnableF2Menu: This entry allows you to determine whether the preference menu should be shown when pressing F2. The default is 1 (true).

Cheers,
  - Andreas


Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Guillermo Polito
In reply to this post by Andreas.Raab
 
Hi!

On Thu, Jan 26, 2012 at 4:41 PM, Andreas Raab <[hidden email]> wrote:
 


On 1/26/2012 15:43, Guillermo Polito wrote:
 


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?
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. Similarly to the OS deciding that (when using dead keys for example) pressing the accent key followed by the a key produces an accented a. Would you expect the keyDown value for the accented a to change as well? This way lies complete madness.

But you're talking about the keychar event and I've not modified at all it's behavior :/.  And yes, I agree I should not do any conversion on KeyUp and KeyDown :).
 

Maybe you don't understand what these events are used for. Consider you are writing a game and you're using shift and control key for primary and secondary weapon action. Would you expect that the person writing the game needs to handle all of the various control and shift key combos in order to find out that the user pressed the a key to move forward?

Oh, yes I do understand.  Maybe I didn't explain me fine, sorry.

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.

Then, after looking at how other platforms work, I reached the conclusion that if events for the same stroke have different keycodes I don't care :), since the keycode should only be important for KeyUp and KeyDown and not KeyChar (where I should only care about charCode).


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.

Which is exactly the right thing to do.

I answered before :).
 

Cheers,
  - Andreas

Thanks, I'm learning!
Guille
Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Guillermo Polito
In reply to this post by Andreas.Raab
 

On Thu, Jan 26, 2012 at 4:45 PM, Andreas Raab <[hidden email]> wrote:

On 1/26/2012 17:00, Igor Stasenko wrote:

Guillermo,
please make the functional keys working on windows. thanks :)

The function keys work perfectly fine on Windows. You need to handle the keyDown events with the proper VK_FXX values, ranging from 0x70 (F1) through 0x87 (F24).

True.  But it would be good if the codes reaching the image for the same function keys are the same :).  But for that there should be a discussion about how to arrange the keycodes to suite the three platforms.

Cheers,
 - Andreas

Guille
Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Andreas.Raab
In reply to this post by Guillermo Polito
 

On 1/26/2012 22:29, Guillermo Polito wrote:
 


Hi!

On Thu, Jan 26, 2012 at 4:41 PM, Andreas Raab <[hidden email]> wrote:
 


On 1/26/2012 15:43, Guillermo Polito wrote:
 


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?
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. Similarly to the OS deciding that (when using dead keys for example) pressing the accent key followed by the a key produces an accented a. Would you expect the keyDown value for the accented a to change as well? This way lies complete madness.

But you're talking about the keychar event and I've not modified at all it's behavior :/.  And yes, I agree I should not do any conversion on KeyUp and KeyDown :).
 

Maybe you don't understand what these events are used for. Consider you are writing a game and you're using shift and control key for primary and secondary weapon action. Would you expect that the person writing the game needs to handle all of the various control and shift key combos in order to find out that the user pressed the a key to move forward?

Oh, yes I do understand.  Maybe I didn't explain me fine, sorry.

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.

The simplest place to do the mapping is inside the image.

Cheers,
  - Andreas


Then, after looking at how other platforms work, I reached the conclusion that if events for the same stroke have different keycodes I don't care :), since the keycode should only be important for KeyUp and KeyDown and not KeyChar (where I should only care about charCode).


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.

Which is exactly the right thing to do.

I answered before :).
 

Cheers,
  - Andreas

Thanks, I'm learning!
Guille
Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Andreas.Raab
In reply to this post by Guillermo Polito
 
On 1/26/2012 22:30, Guillermo Polito wrote:
 



On Thu, Jan 26, 2012 at 4:45 PM, Andreas Raab <[hidden email]> wrote:

On 1/26/2012 17:00, Igor Stasenko wrote:

Guillermo,
please make the functional keys working on windows. thanks :)

The function keys work perfectly fine on Windows. You need to handle the keyDown events with the proper VK_FXX values, ranging from 0x70 (F1) through 0x87 (F24).

True.  But it would be good if the codes reaching the image for the same function keys are the same :).  But for that there should be a discussion about how to arrange the keycodes to suite the three platforms.

We had this discussion already. 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.

Cheers,
  - Andreas


Cheers,
 - Andreas

Guille
Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Guillermo Polito
In reply to this post by Andreas.Raab
 


On Thu, Jan 26, 2012 at 6:39 PM, Andreas Raab <[hidden email]> wrote:
 

On 1/26/2012 22:29, Guillermo Polito wrote:
 


Hi!

On Thu, Jan 26, 2012 at 4:41 PM, Andreas Raab <[hidden email]> wrote:
 


On 1/26/2012 15:43, Guillermo Polito wrote:
 


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?
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. Similarly to the OS deciding that (when using dead keys for example) pressing the accent key followed by the a key produces an accented a. Would you expect the keyDown value for the accented a to change as well? This way lies complete madness.

But you're talking about the keychar event and I've not modified at all it's behavior :/.  And yes, I agree I should not do any conversion on KeyUp and KeyDown :).
 

Maybe you don't understand what these events are used for. Consider you are writing a game and you're using shift and control key for primary and secondary weapon action. Would you expect that the person writing the game needs to handle all of the various control and shift key combos in order to find out that the user pressed the a key to move forward?

Oh, yes I do understand.  Maybe I didn't explain me fine, sorry.

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.

The simplest place to do the mapping is inside the image.

But it's not about the simplest, it's about the better.  The Vm should abstract the image from these things :/.  Tomorrow Dimitry adds support for android specific keys, or I do it for Gtk and etc... and polluting the image with all that seems unnecesary.
 


Cheers,
  - Andreas

Cheers,
Guille
Reply | Threaded
Open this post in threaded view
|

Re: [Windows cog vm] [Keyboard events related] about keycode mapping

Guillermo Polito
In reply to this post by Andreas.Raab
 


On Thu, Jan 26, 2012 at 6:43 PM, Andreas Raab <[hidden email]> wrote:
 
On 1/26/2012 22:30, Guillermo Polito wrote:
 



On Thu, Jan 26, 2012 at 4:45 PM, Andreas Raab <[hidden email]> wrote:

On 1/26/2012 17:00, Igor Stasenko wrote:

Guillermo,
please make the functional keys working on windows. thanks :)

The function keys work perfectly fine on Windows. You need to handle the keyDown events with the proper VK_FXX values, ranging from 0x70 (F1) through 0x87 (F24).

True.  But it would be good if the codes reaching the image for the same function keys are the same :).  But for that there should be a discussion about how to arrange the keycodes to suite the three platforms.

We had this discussion already. 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.

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

Cheers,
  - Andreas


Guille
Reply | Threaded
Open this post in threaded view
|

A couple of keyboard event issues (was Re: [Vm-dev] [Windows cog vm] [Keyboard events related] about keycode mapping)

Juan Vuletich-4
In reply to this post by Guillermo Polito
 
Hi Folks,

This is actually sort of unrelated, but I'm answering to this thread
just because this is also about how VMs report keystrokes in different
platforms. There are 2 things really don't like. It would be great to
have these fixed on the official VMs.

On the mac, when control or command are pressed, for any keystroke the
unshifted code is returned, even if shift is pressed. For instance,
let's assume an US keyboard. So, [shift]+[,] generates $< and
[shift]+[.] generates $>. If you run 'Sensor kbdTest' and press
[shift]+[,] you correctly get $<, but if you press [control]+[shift]+[,]
or [command]+[shift]+[,] you get $,. This is bad, because to detect
[command]+[<] or [control]+[<] you need to write code that not only
needs to know about the platform, but also about the keyboard layout, as
in many layouts $< is not generated by doing [shift]+[,], but by some
other combination. The same happens with most non-alphabetic keys, that
usually differ in different keyboard layouts.

There is a completely separated issue, and it happens both in Windows
and Mac. Here, [ctrl] + [an alphabetic key] substracts 64 from the code.
So, [ctrl]+[c] generates code 3. This is consistent with the traditional
meaning of the ctrl key (in dumb terminals and DOS), but it makes
impossible for the image to tell (for example) between [ctrl]+[Enter]
and [ctrl]+[m]. The image might want to use these keystrokes for
different things, so it would be much better not to substract 64 in the
VM and let the image handle it. I know it could be done by handling key
down and key up events, but this would also require code that is not
only platform dependent but also needs to know the mapping between key
codes and characters in each platform.

In general, I think that [control], [command] and [alt/option] should
not affect the character code of a keystroke, they should only set the
appropriate flag so the image can decide what to do with them. This is
completely different for [shift], as [shift] does indeed modify the
character generated.

I haven't tested on Linux or other platforms, but things like these
could also happen.

Fixing these would enable a few simplifications in the image (at least
in Cuis) and also ease consistent behavior in different platforms. It
would also enable the use of some keystroke combinations involving
[command] and/or [control] that are problematic today.

Thanks,
Juan Vuletich
Reply | Threaded
Open this post in threaded view
|

Re: A couple of keyboard event issues (was Re: [Vm-dev] [Windows cog vm] [Keyboard events related] about keycode mapping)

Guillermo Polito
 
For the Windowze problem, here a Guy wrote down all the problems he found:

http://www.ngedit.com/a_wm_keydown_wm_char.html

Guille

On Thu, Jan 26, 2012 at 10:42 PM, Juan Vuletich <[hidden email]> wrote:

Hi Folks,

This is actually sort of unrelated, but I'm answering to this thread just because this is also about how VMs report keystrokes in different platforms. There are 2 things really don't like. It would be great to have these fixed on the official VMs.

On the mac, when control or command are pressed, for any keystroke the unshifted code is returned, even if shift is pressed. For instance, let's assume an US keyboard. So, [shift]+[,] generates $< and [shift]+[.] generates $>. If you run 'Sensor kbdTest' and press [shift]+[,] you correctly get $<, but if you press [control]+[shift]+[,] or [command]+[shift]+[,] you get $,. This is bad, because to detect [command]+[<] or [control]+[<] you need to write code that not only needs to know about the platform, but also about the keyboard layout, as in many layouts $< is not generated by doing [shift]+[,], but by some other combination. The same happens with most non-alphabetic keys, that usually differ in different keyboard layouts.

There is a completely separated issue, and it happens both in Windows and Mac. Here, [ctrl] + [an alphabetic key] substracts 64 from the code. So, [ctrl]+[c] generates code 3. This is consistent with the traditional meaning of the ctrl key (in dumb terminals and DOS), but it makes impossible for the image to tell (for example) between [ctrl]+[Enter] and [ctrl]+[m]. The image might want to use these keystrokes for different things, so it would be much better not to substract 64 in the VM and let the image handle it. I know it could be done by handling key down and key up events, but this would also require code that is not only platform dependent but also needs to know the mapping between key codes and characters in each platform.

In general, I think that [control], [command] and [alt/option] should not affect the character code of a keystroke, they should only set the appropriate flag so the image can decide what to do with them. This is completely different for [shift], as [shift] does indeed modify the character generated.

I haven't tested on Linux or other platforms, but things like these could also happen.

Fixing these would enable a few simplifications in the image (at least in Cuis) and also ease consistent behavior in different platforms. It would also enable the use of some keystroke combinations involving [command] and/or [control] that are problematic today.

Thanks,
Juan Vuletich