Introduction

Cloudstack console proxy currently supports US keyboard. Other types of non-US keyboard support are
added as a need base.

In 4.0, we built a framework to ease the non-US keyboard support. See the framework description at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Non-US+Keyboard+Support+for+Console+Proxy

In 4.1, as requirements arise, we will add keyboard support for the following three non-US type of
keyboard:

  • simplified Chinese
  • Japanese
  • UK
Design description

To make a non-US keyboard work, the main challenge is to build the key translation table for all the keys on the
keyboard. With the refactoring work done in 4.0, we make this task easier.
The complex flow and algorithm is contained in a special javascript file, ajaxviewer.js.
For each keyboard, we need to find the key mapping table in ajaxkeys.js. For each key, we need to find
its inout key code and its correct output keycode, and put it in the table with correct paramaters.
The ajaxkeys.js will be loaded into the ajaxviewer.js, and carry out the key translation at run time.

There are 6 paramaters to consider when filling the table in ajaxkeys.js:
Parameters on server side:

  1. s_os and s_osVersion: OS type for VM, such as Windows, Linux (Rhel, Centos), ...
  2. s_hypervisor and s_hypVersion: hypervisor type and version, such as Vmware, Xen, LVM, Hyper
  3. s_keyb: VM keyboard, such as English keyboard(EN), Japanese, …

Parameters on client side:

  1. c_os type and c_osVersion: client OS type and version, such as Windows, Linux ... and version;
  2. c_browser and c_browserVersion: browser type and version, IE(IE8, IE9, etc); Firefox, Chrome, Safari
  3. c_keyb: client keyboard, English keyboard(EN), Japanese(jp), ….
    Based on the different combination of the parameters on the server side and the client side, each combination corresponds to one keyboard mapping function f.

We can think of each parameter as a function f, it translates an input keycode to an internal code.
We can think of the mapping in ajaxkeys.js as function g. With all the functions f1 to f6 and g,
they will translate any inout keycode to an output keycode.
g(f1(f2(f3(f4(f5(f6(input_keycode))..) = output_keycode

Hence for each combination of the parameter, we need to figure out the translation function g and
fill in the table in ajaxkeys.js. The other translation functions f is not under our control.
To find out the mapping, we have to do by trial and error for each key on the keyboard.

New key mapping table

Option 1. Use ajaxkeys.js for all the new tables
The majority of the keys, alpha-numeric keys and control keys are handled in the sjaxviewer.js.
Only some distinguished keys for that language have to be specially handled in the ajackeys.js table.
For any new language support to be added, the sjaxkeys.js needs to be modified and a new table to be added.

Option 2.
Another option we can adopt is for any new table to be added, instead of adding to the ajaxkeys.js file,
we create a new file and the ajaxviewer.js has to be modified to parse this new file at the proper
location in the file.

We also need to adopt a consistent naming convention for the new file to be added. For example, we
can use languageX_hypervisorName_OS_Version_Browser_Version_keys.js for a new table for a
combination of hypervisorName, OS with Version, Browser with Version, for languageX.

Requirements

The requirements are especially important for this feature.
Since the combination of all the 6 parameters can grow quite large, we need to scope the task properly
with specific parameter combination for the release.

  • Simplified Chinese:
    Chinese input uses US keyboard (Chinese IM may use Pinyin or Sogou).
  • Japanese:
    Browser: IE & firefox; (what is the version number?)
    OS and version: Windows, Unix
    hypervisor: XS, KVM, vSphere
  • UK keyboard:
    Browser: IE & firefox; (what is the version number?)
    OS and version: Windows, Unix
    hypervisor: XS, vSphere
Non-requirements
  • Browser: Chrome, Safari;
  • hypervisor:
  • OS:
Debugging process

To find out the Input_keycode, we can turn on the keyboard logger window which will show the keycode for every key pressed. “CTRL-ATL-SHIFT+SPACE” turns on the logger. To have a fresh window to show the code for a new key, clear the window first, and then press a key.
More description at the reference document.

References and bugs

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Non-US+Keyboard+Support+for+Console+Proxy

Three bugs to rtack each of the non-US keyboard:

https://issues.apache.org/jira/browse/CLOUDSTACK-956

https://issues.apache.org/jira/browse/CLOUDSTACK-957

https://issues.apache.org/jira/browse/CLOUDSTACK-958

  • No labels