Hey guys,
When my hardware keyboard is connected/paired with my Android device, key events do contain a scan code. I would love to just send that scan code through to the VM, however, the Android documentation is really discouraging on this matter.
Can you guys take a look at the docs for the method which retrieves the scan code, and tell me whether you would rely on the value returned by getScanCode() given what's written?
http://developer.android.com/reference/android/view/KeyEvent.html#getScanCode%28%29
In addition, my hardware keyboard has an English layout, and I have no way of testing what a hardware keyboard with a non-English layout generates when one presses a key which is not in the ASCII table. The reason it's interesting is that Android key events may contain a key code, and scan code. The documented key codes for Android are all within the ASCII table. When a soft-keyboard KeyEvent carries unicode data outside the ASCII table, its key code == 0, and its "action" is not DOWN or UP, but MULTIPLE. So, will (for example) a German hardware keyboard on which u-umlaut is pressed generate an event with action == ACTION_MULTIPLE and a key code == 0, or will it generate an event with action == DOWN/UP and key code set to something inaccurate? Does anybody own an Android and a hardware keyboard with a non-English layout to help me test this?
When my hardware keyboard is connected/paired with my Android device, key events do contain a scan code. I would love to just send that scan code through to the VM, however, the Android documentation is really discouraging on this matter.
Can you guys take a look at the docs for the method which retrieves the scan code, and tell me whether you would rely on the value returned by getScanCode() given what's written?
http://developer.android.com/reference/android/view/KeyEvent.html#getScanCode%28%29
In addition, my hardware keyboard has an English layout, and I have no way of testing what a hardware keyboard with a non-English layout generates when one presses a key which is not in the ASCII table. The reason it's interesting is that Android key events may contain a key code, and scan code. The documented key codes for Android are all within the ASCII table. When a soft-keyboard KeyEvent carries unicode data outside the ASCII table, its key code == 0, and its "action" is not DOWN or UP, but MULTIPLE. So, will (for example) a German hardware keyboard on which u-umlaut is pressed generate an event with action == ACTION_MULTIPLE and a key code == 0, or will it generate an event with action == DOWN/UP and key code set to something inaccurate? Does anybody own an Android and a hardware keyboard with a non-English layout to help me test this?
As things stand, if I don't trust the scan code the keyboard generates, I cannot use my English layout hardware keyboard to type any language other than English because the scan codes are simulated based on the unicode character the event contains. On my English keyboard, the event inevitably contains unicode characters that fall within the ASCII table, as you can imagine :).
Your thoughts and suggestions are welcome.
Thanks!
iordan
iordan
--
The conscious mind has only one thread of execution.
The conscious mind has only one thread of execution.
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel