[squeak-dev] VM side EventSensor design questions

Hi all.

I'm writing my own EventSensor class (as part of Subcanvas: http://gulik.pbwiki.com/Canvas) and I'm looking at what the VM is doing.

When I press and release key under a recent Linux VM, I get three events:

#(2 512613 53 1 8 0 0 0)
#(2 512613 53 0 8 0 0 0)
#(2 512664 53 2 8 0 0 0)

The fields are (for those that don't already know this):

1: type (2=keyboard),
2: timestamp,
3: character in Mac Roman encoding,
4: key press/release (0=character, 1=press, 2=release)
5: modifiers (1=shift, 2=ctrl, 4=mac option, 8=cmd/alt)

and the rest of the fields are unused afaict.

Now, why do I get both a key pressed event and a character event? The key pressed event already has the character information. Is there a circumstance where these two events would differ in anything other than the type of event?

The VM doesn't send any events for only a shift/ctrl/alt key press or release. Should it?

If you hold down a key, you get a stream of key press and character events for the same key. Should it? I'd prefer to have character repetition handled within the image so that arcade games could be implemented.

Finally, I'm lazy, so I'm going to ask this mailing list how Unicode input has been handled rather than read code. Do implementations modify the VM to send Unicode characters through as field 3 (or whatever) of the input arrays? Or do the implementations take the Mac Roman encoding from the event array, look up a keyboard mapping in the image and convert the result to the correct Unicode character?

Gulik.

--
http://gulik.pbwiki.com/

On a random Windows VM I just found, I get even more interesting results:

#(2 14856453 72 1 0 72 0 0)
#(2 14856453 104 0 0 104 0 0)
#(2 14856500 72 2 0 72 0 0)

The character changes. I typed in a lower case 'h', but the VM returns an upper-case 'H' (72) as the press and release field character, and a lower case 'h' (104) in the character field.

Why?

And why is the character repeated in the 6th field?

Also, under the Windows VM, modifier key pressed and releases /are/ sent to the VM.

Gulik.

--
http://gulik.pbwiki.com/

Everything you want to know is documented here
http://isqueak.org/ioGetNextEvent

but I might have missed something or things have changed since last fall

On Tuesday, June 23, 2009, Michael van der Gulik <[hidden email]> wrote:
--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================

--
http://gulik.pbwiki.com/

[BTW, I think this discussion is more appropriate for vm-dev]

Michael van der Gulik wrote:
> The fields are (for those that don't already know this):
>
> 1: type (2=keyboard),
> 2: timestamp,
> 3: character in Mac Roman encoding,
> 4: key press/release (0=character, 1=press, 2=release)
> 5: modifiers (1=shift, 2=ctrl, 4=mac option, 8=cmd/alt)
>
> and the rest of the fields are unused afaict.

http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Cross/vm/sq.h

/* keyboard input event */
typedef struct sqKeyboardEvent
{
   int type; /* EventTypeKeyboard */
   unsigned int timeStamp; /* time stamp */
   int charCode; /* character code in Mac Roman encoding */
   int pressCode; /* press code; any of EventKeyXXX */
   int modifiers; /* combination of xxxKeyBit */
   int utf32Code; /* UTF-32 unicode value */
   int reserved1; /* reserved for future use */
   int windowIndex; /* host window structure */
} sqKeyboardEvent;

> Now, why do I get both a key pressed event and a character event? The
> key pressed event already has the character information. Is there a
> circumstance where these two events would differ in anything other than
> the type of event?

Yes. Whenever you have key combinations like dead keys you will see
multiple key down events and only one corresponding character event. At
least that's the idea I don't know how far the Unix VM implements it.

Basically the rule is: You should get a keyDown/keyUp event for every
physical key you press/release on your keyboard, be that a letter key, a
a navigation key, a composition key, or a meta or function key. A
keyStroke event is generated for any combinations of keys that produce
actual characters.

(BTW, this rule implies that the generation of character events for
navigation keys (arrow key, home/end, function keys) is incorrect)

> The VM doesn't send any events for only a shift/ctrl/alt key press or
> release. Should it?

Yes. It's a key you are pressing. If it can generate an event it should
do so.

> If you hold down a key, you get a stream of key press and character
> events for the same key. Should it? I'd prefer to have character
> repetition handled within the image so that arcade games could be
> implemented.

It's difficult to properly map this to the (dynamic) auto key repeat
frequency. So I think it should do it, yes.

> Finally, I'm lazy, so I'm going to ask this mailing list how Unicode
> input has been handled rather than read code. Do implementations modify
> the VM to send Unicode characters through as field 3 (or whatever) of
> the input arrays? Or do the implementations take the Mac Roman encoding
> from the event array, look up a keyboard mapping in the image and
> convert the result to the correct Unicode character?

See above. It's reported as utf32 in the event.

Cheers,
   - Andreas

Michael van der Gulik wrote:
Look at your keyboard. Real close. What does the letter that is printed
on the keyboard say? Does it say "h" or does it say "H"? ;-)

When you press the "H" key (as it is denoted on your keyboard) the VM
reports this as the "H" key which is then interpreted by Windows to be
the lowercase "h" character, which it reports as well. Similarly, if you
would press Shift-H, it would report that you pressed the shift key, the
"H" key which then resulted in the uppercase "H" character. Makes sort
of sense dunnit? ;-)

> And why is the character repeated in the 6th field?

Because the Windows VM is fully Unicode capable and produces both
MacRoman as well as UTF-32 for maximum compatibility.

> Also, under the Windows VM, modifier key pressed and releases /are/ sent
> to the VM.

Yes, indeed. You are pressing that shift key, no? Why would the VM not
report that? Might as well decide not to report the Q key ;-)

Cheers,
   - Andreas

Gulik.

--
http://gulik.pbwiki.com/

There are a Windows API functions, which can be helpful for handling a
keyboard input almost independetly from windows messaging
implementation.

There are two useful function, which, when use the wisely could
replace the keyboard input handling:
GetKeyboardState
- fills an array with each key state (down/up + swither on / swithed off)

MapVirtualKey
- this function maps between key code <==> virtual key

so, you can implement a keyboard repeat in image, while in VM,
generate only keydown/keyup events.


2009/6/24 Andreas Raab <[hidden email]>:


--
Best regards,
Igor Stasenko AKA sig.

On 24.06.2009, at 06:46, Andreas Raab wrote:

>> If you hold down a key, you get a stream of key press and character  
>> events for the same key. Should it? I'd prefer to have character  
>> repetition handled within the image so that arcade games could be  
>> implemented.
>
> It's difficult to properly map this to the (dynamic) auto key repeat  
> frequency. So I think it should do it, yes.


Indeed. The convention we agreed upon for auto-repeat is that you get  
a key-down event when you press the key, and then more key-down events  
for the repeats the system generates, followed by a single key-up when  
the key is physically released.

I'm not sure each VM follows this convention yet.

- Bert -

On 24.06.2009, at 05:06, John McIntosh wrote:

> Everything you want to know is documented here
> http://isqueak.org/ioGetNextEvent
>
> but I might have missed something or things have changed since last  
> fall


Yes, after a lot of tweaking, Unicode keyboard stroke events are  
believed to work fine in the Unix VM now.

- Bert -

Bert Freudenberg wrote:
Unless you have a composing keyboard, which gives you really interesting
event sequences...

Michael

Here the topic which completely covers all the differences of keyboard
keys mapping on 3 main OSes

http://classicteck.com/rbarticles/mackeyboard.php

if we extract the data from there, we can add this information to
events (in keyboard event record there are unused slots)
so, then at image side we can translate the key presses completely
without dependency from OS.
I mean, you can make 'A' key work as 'shift' key etc :)

P.S. Of someone of you had luck working on Yamaha PCs , especially on
Yahama 2 - with slim keyboard!!
This was a best keyboard i ever seen since late of 1980's . Only last
5 years a PC market producing a similar keyboards with touch & feel.
Concerning technical decision, how they made a keyboards:
- there was a memory region (or io ports region - don't remember
exactly), which on read, gives you a bit map, which shows what keys
are currently held down (with 1's ) and what is not (with 0's). There
was no difference how much keys you press down - all of them is
reported in this key bitfield. In contrast, on PCs there was some
defective (by design) keyboards, which can't handle more than 4 keys
pressed. This was especially annoying , when you playing a Mortal
Combat with friend in a hot seat (both have to hold multiple keys) -
if you hold down more than a 4 keys, keyboard starts beeping and
ignoring input. And one of players starts losing , because can't
control his character. Not very fun gameplay :)

In contrast, on Yamaha (years before PC's swallowed the market), all
keys, no matter how many of them is held down is reported & handled.
There also, was a different keyboard repeat handling (which i REALLY
miss on PC):
If you first press 'a', and hold it down, then press 'b' and hold it
too, after delay, it starts repeating these keys in same sequence as
you pressed them:
abababab

so, without any software , which supports text formatting/macros/other
helpers, you can format your code just using keyboard.
For instance, if you want to indent multiple lines of text, you can
quickly press and hold following keys:
- tab
- down arrow
- home

and obviously, if you repeat the keystrokes in such order, your text
will start indenting untill you think its enough.
There were many possible combinations, which you will never have a
chance to repeat on PC's , even if you have an uber-text-macro helpers
:)
Such a little difference - but such huge usability effect.

2009/6/25 Michael Rueger <[hidden email]>:


--
Best regards,
Igor Stasenko AKA sig.