Archive:Keyboard Internationalisation
Keyboard Internationalisation
Input Processing
Different input devices can be attached to the xbmc:
- gamepad
- remote
- universal remote
- keyboard
All these devices have several hardware buttons. A keyboard can have up to 256 keys (send 256 different scancodes). Real/usual keyboards do not really have 256 keys, they have about 100+ keys, thus not all scancodes are used and can occur. The scancodes have a number from 0 to 255 (decimal). From now on till the press of one button starts an action in xbmc several mappings take place.
1. Symbolic scancode names (DirectInputKeyboard.cpp): in the source code the scancodes also have symbolic names which are more readable and comprehensible. The position of the key with the symbolic name DIK_A on the keyboard is nearly always on the left side of the keyboard and is usually labeled with A. This is the first mapping (from scancodes to key labels of english keyboards). The most common PC keys are standardized. But producers of PC keyboards always have been creative inventing unconventional keyboards with unconventional keys (e.g. 24 function-keys from IBM?, windows keys from MS). Funnily enough today there is a trend for multimedia keyboards with multimedia keys. But those unconventional keys do not have a standardized mapping or symbolic name anymore. The only chance to process such keys is processing the raw scancode, that still is in the range from 0 to 255. This will be addressed in suggestion of a solution at the end of this text. But first further (keyboard) input processing is explained.
2. Real label mapping/keyboard layout (DirectInputKeyboard.cpp): allthough the symbolic name always refers to the usual label of a keyboard with english layout (QWERTY), the real label is not always the same as the symbolic name suggests. (Only the physical position of the key on the keyboard should always be the same!) Keyboards that do not have an english layout, e.g. german keyboards often/always use the same physical implementation of the keyboard, that always send the same scancodes if you press the same keys on the same physical position, but those keys maybe and often are labeled different, e.g. german keyboards always interchange the labels of Y and Z (QWERTZ) in contrast to english keyboards. And nearly all other keys besides a to z and 0 to 9 are labeled different, e.g. <>,;.:-_#'+*"§$%&/()=?{[]}\ and so on. If the software ignores this fact, like xbmc does till now, such a keyboard is nearly useless. So it is necessary to make a second mapping from scancodes or symbolic names to the real labels. This is the topic of the following suggestion for a solution for national or individual keyboard layouts at the end of this text, too. At the moment xbmc does not map real labels! This mapping is necessary (for other keyboards than english ones or special/individual keyboards) but does not take place in xbmc till now.
3. Simultaneous key combination mapping (DirectInputKeyboard.cpp): if the user only presses the key labeled with "1" (with the symbolic name DIK_1), the number "1" should be processed. If the user additionally presses a second key labeled with "shift" at the same time, the character "!" should be processed. Thus, pressing several physical keys should be processed as if only one totally other key has been pressed (should be "mapped"). Solving this problem is also part of the solution suggested at the end of this text. And this is the level where the mentioned solution ends!
4. Character encoding: even, if you now know, that you want to process a character "!" how should this and all the other characters be encoded binary? Historically this is done with 7 bit and ascii encoding.Unfortunately this is not enough for encoding all the possible characters that are known and needed worldwide, e.g. for german umlauts. Till now, xbmc processes only ascii and is not able to process all/any special national characters like german umlauts from keyboard input. Conceptual the simplest solution today would be the use of unicode, e.g. UTF16 (or WCHAR in the programming language C++) but this will very probably need much rework of the xbmc code and the use of most of its libraries. Solving this problem is NOT part of the solution suggested at the end of this text. The additional complicaton of special national characters like german umlauts is negligible in comparison to the mentioned problem of real label mapping, at least for german keyboards. Nevertheless this is the next problem of (keyboard input) processing and character processing in general.
5. xbmc key codes (ButtonTranslator.cpp): as mentioned at the beginning of this text, keyboard input is not the only possibility of input for xbmc. All other devices have something similar like scancodes and such mappings. All those different inputs and buttons and ascii characters are finally mapped and "merged" into one internal xbmc key code that ranges from 0 to 65535 (2^16-1 or 2 Bytes).
6. Symbolic key mapping (ButtonTranslator.cpp): it is possible to customize, what should happen in xbmc, if these buttons/keys are pressed (keymap.xml). To be able to use comprehensible names of these buttons instead of knowing their xbmc internal key code/number, there is a mapping from comprehensible key names to the internal key codes.
7. Actions and scripts: finally, the symbolic key names can be assigned (mapped) to actions or scripts within keymap.xml to customize, what should happen, when a physical key is pressed.
Suggested solution for keyboard internationalisation
- to use keyboards that don't have an english layout
- to use additional multimedia keys
- to customize key combination mappings
- besides mapping of special national characters like german umlauts
A new XML customization file keyboardlayout.xml could be created. It could look like the following example:
<xml> <keyboardlayout> <kc48>a</kc48> <kc_dik_b>b</kc_dik_b> <kcxxx>0x1B</kcxxx> <! map esc key to vkey 0x1B --> <kcyyy>p</kcyyy> <shift> <kc48>A</kc48> <kc_dik_b>B</kc_dik_b> <kcxxx>0x1B</kcxxx> <! map esc key to vkey 0x1B --> <kcyyy>s</kcyyy> </shift> <ctrlshift> ... </ctrlshift> </keyboardlayout> </xml>
The goal is at least to be able to map every scancode and usual key combination (shift, ctrl, alt, alt gr) to any already in xbmc existing ascii or vkey (currently about 158 possibilities).
This XML-file must be read and the resulting map must be used within DirectInputKeyboard.cpp, when evaluating the scancodes (Update).
XBMC could be delivered with such a default configuration of this XML for every language. At the beginning the configuration for an english keyboard is default for every language. Other languages could be added/modified subsequently. Individual/personal customizations are always possible additionally.