[webbanane]

Hi alltogether!

I have a new nice media center keyboard with integrated trackball and some media keys (http://www.speedlink.de/prod.php?lang=de...L-6495-SSV Speed-Link SL-6495-SSV Media Centre Controlboard). It has a german layout and german special keys like german umlauts. The hardware nearly works perfectly. Unfortunately xbmc doesn't support international keyboards and unicode input (only english keyboard layout and ascii).

I know C++, I have but I don't know xbmc-source and don't have and know xdk and MS VC++. Nevertheless I want to and hope am able to add support for my keyboard and not only for my keyboard but also for other international keyboards, media keys and perhaps unicode in a reasonable way, i.e. I don't want to invest months of work into this. Therefore I search a quick/simple solution. I dont' want to memorize all inner workings and rework whole xbmc source and libraries(?) ;-)

I have linux and gcc and assume I will be able to compile my code, but I am not able to build and test xbmc on my own. I need support for several reasons and hope to get it.

In this thread I want to sketch and discuss such a solution and hope to get some hints from you, so that I avoid meanders, but I won't wait till this discussion ends, I will start immediately with the following solution.

I already talked to jmarshall and found out, that the following things are already available in xbmc:
* XBoxKeyboard (trunk): support for keyboards connected to xbox (via XDK)
* DirectInputKeyboard (trunk): support for keyboards (via win32)
* SDLKeyboard (linux port branch): support for keyboards via SDL-Framework (via win32?)
* All implement the same class CKeyboard with nearly the same signature/interface. I assume they are bound at build time (not by runtime configuration, separate interface and factory).

I hope that all (especially the XBoxKeyboard) support direct access to so called scancodes (low level representation of the physical keys). This seems to be the most important thing to be able to add support for international keyboards.

I documented some inner workings in the wiki:
http://www.xboxmediacenter.com/wiki/inde...nalisation

I think the following requirements are relevant, not necessarily all implemented (only wishes):
* mapping of any key press to any xbmc action
* support keyboards that don't have english layout (correct international layout of a-z, A-Z, 1-0 etc.)
* support additional multimedia keys (model or individual configuration)
* support special national keys and characters (german umlauts etc.)
* support customization of key combinations (e.g. 'ALT GR' + 'Q' for '@' on german keyboards)
* support unicode characters (german umlauts maybe mapped to latin-1 codepage but that does not work for all international characters, e.g. it does not work for the dutch 'ij' with decimal code 307)
* allow national, model and individual configuration in an xml-file
* one solution for all plattforms (xbox, win32, linux or XBoxKeybaord, DirectInputKeyboard and SDLKeyboard respectively; program it only once for all)

Following is a solution sketch:
* abstract all low level differences between different plattforms/implementations behind a common interface other than CKeyboard
* this interface contains scancodes, english layout and ascii characters
* add all additional features on top of that interface in class CKeyboard
* use this new class CKeybaord with additional features instead of the old class cKeybaord mentioned above
* dont' remove current ascii feature foremost, to be backwards compatible
* put new unicode feature alongside of ascii, to enable the new feature, but this still requires further work to use it and I don't know how much work till now, to use it throughout in xbmc
* create new keyboardlayout.xml and put one of it into each language specific folder
* At the beginning the configuration for an english keyboard is default for every language. Other languages could be added/modified subsequently. Model specific or individual/personal customizations are always possible additionally and can be collected and exchanged elsewhere.
* Such an XML could look like this:

<keyboardlayout>

<kc48>1</kc48> <!-- map physical key wich keycode/scancode 48 to character '1' -->
<kcxxx>0x1B</kcxxx> <!-- map physical key with scancode xxx key to vkey 0x1B -->
<kcyyy>p</kcyyy> <!-- map multimedia play key with scancode yyy to ascii p -->
<kczzz>0x0133</kczzz> <!-- map physical key with scancode zzz to dutch unicode character 'ij' -->

<shift>
<kc48>!</kc48> <!-- map physical key with keycode/scancode 48 in combination with shift key to character '!' -->
<kcyyy>x</kcyyy> <!-- map multimedia play key in combination with shift to ascii x (stop) -->
</shift>

<ctrlshift>
...
</ctrlshift>

</keyboardlayout>

* read the xml for the current language, generate an internal map of physical keys to logical keys/characters
* use that map in the class with additional features

open questions to XDK functionality:
1. Are VirtualKeys representations of the physical keys, e.g. "main-enter" and "numpad-enter" separated or are they already translated to "logical" functions like "only one enter"?
2. Are VirtualKeys always "filled" even if ascii is "filled"?
I'm sure more questions will arise.

What do you think of the solution? Can you answer my other questions? And who can help me build xbmc and test it?

Best regards

webbanane

[Gamester17]

Not directly related but good to know / keep in mind for reference:
OSD Virtual Keyboard with QWERTY for PM3 (see the comments)



http://en.wikipedia.org/wiki/Keyboard_layout

[webbanane]

Oh, the link to the wiki nicely shows the real variety and complexity that exists. And it could be a good base for first national configurations.

Addditonally it mentions the concept of dead keys, this could be another requirement, but I won't implement it with the first version. Nevertheless additional features like such things hopefully could be implemented on top of the low level interface.

[webbanane]

Here are some more details about my current implementation decisions:

1. As mentioned above before my modification, there have been three relevant header and cpp file pairs with different keyboard implementations (XBoxKeyboard, DirectInputKeyboard, SDLKeyboard). But they all implement the same class named "CKeyboard". Therefore it is not possible to compile all together in the same build. Only one of it can be compiled in one build.

a) I renamed those from "CKeyboard" to "LowLevelKeyboard". Now the class CKeyboard is not used anymore.
b) I created a new file pair KeyboardMapping with a new class CKeyboard with the same name and interface of the old class(es) for backwards compatibility.

2. There is a global variable g_Keyboard as before.

3. The LowLevelKeyboard is a hidden member in the new CKeyboard class.

[webbanane]

Now I have some questions where to place the modules in the directory hierarchy.

The folder /guilib/common contains
XBoxKeyboard
DirectInputKeyboard
SDLKeyboard

I assume this folder is thought of as a kind of central/core directory.

Question (#3): are those classes allowed to have dependencies to other classes in other directories e.g. /xbmc?

If I get no answer to this question I will assume they are not allowed.

Question (#4): more general, what are the "common" rules? (Opened new thread for this: http://forum.xbmc.org/showthread.php?tid=26824)

I plan to do one module ScancodeMapping that reads the xml and holds the map.

Question (#5): should I place it in /xbmc like Settings, GUISettings?

If I get no answer to this question I will assume: YES.

As I already said, I also do a KeyboardMapping module that uses the three different plattform keyboards and the module ScancodeMapping. On one side it depends on other modules and perhaps should not go to /guilib/common, but on the other side it replaces the old CKeyboard which "always" has been there.

Question (#6): should the module KeyboardMapping go to /xbmc like ButtonTranslator?

If I get no answer to this question I will assume: YES.

[webbanane]

Do you want to taste it? :o)

[jmarshall]

Nice work

[webbanane]

Hi there!

I supplied the first patch:

http://sourceforge.net/tracker/index.php...tid=581840

Hope it works ;-)

[internick]

Congratulations webbanane:

that's great. Surely it would help me. I'm using onAction getButtonCode() and a label to make my own inputbox without showing the on screen keyboard.

Waiting for your news...

[webbanane]

Hi internick!

Thanks, I'm glad someone (you) answers on this thread, but it's not up to me. Till now, I did everything I can do.

My code already has been reviewed a bit and been found o.k., but as far as I can see the great guys from XBMC Team are very hard-working on other things, mostly (I don't know how they can accomplish that, anyway.)

Perhaps it might help, if further people tell how urgent they need this feature

[weinerschnitzel]

This feature does seem really useful for the German audience out there. There are quite a few features I see on the forums that seem very worthy and magnificent enough to be in the main SVN trunk. It seems that Team XBMC is very proud of their extreme stability with the SVN trunk. That comes from very strict feature additions. I personally feel that some things need to be added into the trunk anyway to "push the package," if you will. To me I think that xbmc can evolve much faster than it already does. Many projects here are very neat, but lack the support of others to help it along. Projects like this, I think, should be added anyway because they are small enough not to make a major impact on the SVN's stability.
My 2 cents, hope it helps the furthering of this feature.

[PANIC!]

Sounds great! I am also very interested in a german keybaord layout. Would be useful in many places like IMDb searches etc. IMDb gets it most of the time when i type an o instead of an ö.

Just my two cents.

[internick]

Hello!

could you tellme why does .getButtonCode() returns that values?
if i push "a" - 61505
"b" - 61506
... and so on ...

Sorry i'm a python begginer

[webbanane]

Yes, I can! If you have a look here:

http://xbmc.svn.sourceforge.net/viewvc/x...iew=markup

You will see a constant KEY_VKEY defined as 0xF000.
The decimal value of this is 61440.
The difference to your number for "a" is 65!
65 is the ASCII code for "a".

So every time you press "a". The ascii code is added to KEY_VKEY and processed this way.

As you can see in:
http://www.xboxmediacenter.com/wiki/inde...nalisation
(Number 9) this is the way it is done within XBMC till now.

BUT I am wondering a bit, because it should be KEY_ASCII (0xF100 = 61696) not KEY_VKEY that is added. Since VKEY represents not printable codes (like arrow keys) and KEY_ASCII represents printable characters. But I already found and communicated a bug that may be associated with this. But till now I thought this bug had no relevant consequences. Maybe it is also another bug.

[internick]

Thak you again Webbanane

that's great. That's all i need.

Let's work