On Wed, Jun 24, 2009 at 4:52 PM, Andreas Raab andreas.raab@gmx.de 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.
2009/6/25 Michael van der Gulik mikevdg@gmail.com:
On Wed, Jun 24, 2009 at 4:52 PM, Andreas Raab andreas.raab@gmx.de 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.
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 siguctua@gmail.com:
2009/6/25 Michael van der Gulik mikevdg@gmail.com:
On Wed, Jun 24, 2009 at 4:52 PM, Andreas Raab andreas.raab@gmx.de 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.
-- Best regards, Igor Stasenko AKA sig.
squeak-dev@lists.squeakfoundation.org