[squeak-dev] International keyboard questions

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

[squeak-dev] International keyboard questions

Michael van der Gulik-2

On Wed, Jun 24, 2009 at 4:52 PM, Andreas Raab <[hidden email]> wrote:
Michael van der Gulik wrote:
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?

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? ;-)

Not any more :-). I found this: http://www.win.tue.nl/~aeb/linux/kbd/scancodes-14.html

I think that using the USB scan codes would make more sense. It's a "standard", although so far I've only found Microsoft to be declaring it as such. I haven't investigated finding out if X11, Win32 and the Macintosh APIs allow you access to them directly, but if they don't, I can still convert the VM's "characters" for the key press and key release events to this standard. Using this "standard" means that the VM's input events are the same across all platforms.

I think I'm satisfied that the scancodes are the same across the vast majority of modern keyboards around the world. There seems to be two types of hardware keyboards being made: a US one and a European one. The rest of the world's keyboards seem to be one of these two models with different printing on them. Let me know if this assumption is wrong.

International keyboard mappings:
http://msdn.microsoft.com/en-gb/goglobal/bb964651.aspx

Gulik.

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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] International keyboard questions

Igor Stasenko
2009/6/25 Michael van der Gulik <[hidden email]>:

>
> On Wed, Jun 24, 2009 at 4:52 PM, Andreas Raab <[hidden email]> wrote:
>>
>> Michael van der Gulik wrote:
>>>
>>> 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?
>>
>> 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? ;-)
>
> Not any more :-). I found this:
> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-14.html
>
> I think that using the USB scan codes would make more sense. It's a
> "standard", although so far I've only found Microsoft to be declaring it as
> such. I haven't investigated finding out if X11, Win32 and the Macintosh
> APIs allow you access to them directly, but if they don't, I can still
> convert the VM's "characters" for the key press and key release events to
> this standard. Using this "standard" means that the VM's input events are
> the same across all platforms.
>
> I think I'm satisfied that the scancodes are the same across the vast
> majority of modern keyboards around the world. There seems to be two types
> of hardware keyboards being made: a US one and a European one. The rest of
> the world's keyboards seem to be one of these two models with different
> printing on them. Let me know if this assumption is wrong.
>
I can tell you that i never seen a non-US-compatible keyboards for PC
during my more than 20years computers experience. :)

> International keyboard mappings:
> http://msdn.microsoft.com/en-gb/goglobal/bb964651.aspx
>
wow, good find!
It means, that by having a scan code translation tables, we can
support almost all input languages, and they can be handled by image.
While VM can care only about scan codes.

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



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] International keyboard questions

Igor Stasenko
Recalling the old PC-XT/PC-AT days :)

http://wiki.osdev.org/PS2_Keyboard

not much changed since then with keyboards.
OS-es still using port 60 to read the keyboard scan codes.

Maybe things in BIOS have changed to support USB keyboards.. but any
side steps from ol-gray standard brings only problems & confusion to
users. Try googling 'USB keyboards BIOS' to see how much headache the
people have, when there is no USB => Legacy keyboard support, or its
turned off in BIOS.
Still, i think scan codes for USB keyboards remain the same - there is
no reason to change them.

Scan codes explained in depth:
http://www.quadibloc.com/comp/scan.htm

2009/6/25 Igor Stasenko <[hidden email]>:

> 2009/6/25 Michael van der Gulik <[hidden email]>:
>>
>> On Wed, Jun 24, 2009 at 4:52 PM, Andreas Raab <[hidden email]> wrote:
>>>
>>> Michael van der Gulik wrote:
>>>>
>>>> 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?
>>>
>>> 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? ;-)
>>
>> Not any more :-). I found this:
>> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-14.html
>>
>> I think that using the USB scan codes would make more sense. It's a
>> "standard", although so far I've only found Microsoft to be declaring it as
>> such. I haven't investigated finding out if X11, Win32 and the Macintosh
>> APIs allow you access to them directly, but if they don't, I can still
>> convert the VM's "characters" for the key press and key release events to
>> this standard. Using this "standard" means that the VM's input events are
>> the same across all platforms.
>>
>> I think I'm satisfied that the scancodes are the same across the vast
>> majority of modern keyboards around the world. There seems to be two types
>> of hardware keyboards being made: a US one and a European one. The rest of
>> the world's keyboards seem to be one of these two models with different
>> printing on them. Let me know if this assumption is wrong.
>>
> I can tell you that i never seen a non-US-compatible keyboards for PC
> during my more than 20years computers experience. :)
>
>> International keyboard mappings:
>> http://msdn.microsoft.com/en-gb/goglobal/bb964651.aspx
>>
> wow, good find!
> It means, that by having a scan code translation tables, we can
> support almost all input languages, and they can be handled by image.
> While VM can care only about scan codes.
>
>> Gulik.
>>
>> --
>> http://gulik.pbwiki.com/
>>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.