[Freerdp-devel] Japanese Keyboard not working

[Seiji T]

Dear all,

I am trying to get 109 Japanese Keyboard (*1) to work with freerdp without
success.

(*1) Actually the 109A keyboard. I am told that it is very similar to
109 and the difference between them is minimal, as shown in the
2nd image of the following link (Sorry in Japanese):
http://home.impress.co.jp/magazine/dosvpr/q-a/0305/qa0305_1.htm
+ Note the "~" highlighted in grey, you can ignore the rest.

I haven't checked all the keys but some keys, particulary at the right
side of the keyboard (*2) doesn't seem to work as intended.

(*2) Some examples represented in this picture, right-side keys with
scancode highlighted on them.
Loading Image...
-> goto http://www.win.tue.nl/~aeb/linux/kbd/scancodes-8.html to
see imprinted symbols on key.

I am still unable to get the RDP server to correctly recognize the keys
and I would very much appreciate if anyone can help me fix this issue.

Here's what I did/found so far: (A bit too long but please bear with me)

I had no clue as to what might be wrong so I put my focus on the "\|"
keycap (and work my way up to other keycaps).

Here is my understanding of keycodes and scancodes for "\" (compiled
from various sources):

X11 keycode: AE13(0x84) #(*3)
Virtual keycode: VK_OEM_5 (0xDC) #(*4)
scancode #: 0x7D #JIS109 Keyboard(*5)

(*3) /usr/share/X11/xkb/keycodes/evdev
(*4) http://www.win.tue.nl/~aeb/linux/kbd/scancodes-8.html
(*5) http://msdn.microsoft.com/en-us/library/ms892472.aspx

Downloaded the latest source 131c19f (at the time) on Xubuntu 11.10,
and enabled DEBUG_KBD. I run the executable and here's what I got:

DBG_KBD detect_keyboard_layout_from_xkb (378): display: 0x9384270
DBG_KBD detect_keyboard_layout_from_xkb (382): layouts: jp
DBG_KBD detect_keyboard_layout_from_xkb (383): variants:
DBG_KBD detect_keyboard_layout_from_xkb (390): group: 0
DBG_KBD detect_keyboard_layout_from_xkb (395): layout: jp
DBG_KBD detect_keyboard_layout_from_xkb (396): variant:
DBG_KBD find_keyboard_layout_in_xorg_rules (908): xkbLayout: jp xkbVariant:
DBG_KBD freerdp_keyboard_init_xkb (336):
detect_keyboard_layout_from_xkb: E0010411

[Mads Kiilerich]

Post by Seiji T
Dear all,
I am trying to get 109 Japanese Keyboard (*1) to work with freerdp without
success.

I guess a part of the real could be that the FreeRDP settings for
kbd_type and kbd_subtype and kbd_fn_keys always are 0 when xfreerdp
sends Client Core Data in gcc_write_client_core_data .

That is according to http://msdn.microsoft.com/en-us/library/cc240510
not valid, and for japanese keyboards you might have to use keyboardType
7. That could in principle also change the rdp scan codes completely.

I don't know if correct values for these settings can be determined from
X (or windows) information somehow.

If mstsc from windows works correctly then you could try to dump and
analyze what it sends so we know how we could make it work.

/Mads

[Marc-André Moreau]

I have never tried making any of the CJK languages work due to lack of
knowledge regarding those. There is indeed significant differences in the
way those need to be handled, we need to pass an IME file along with a
different keyboard type I believe.

If you have general information on how those keyboards work, it would help.
If I understood correctly words are written phonetically and the IME would
suggest a possible kanji for it, which you can accept with a special key?

I honestly don't know that much about Japanese and CJK input methods, I
guess that for Japanese hiraganas and katakanas could be used for typing in
words phonetically and then replace them with a kanji if necessary.

Feel free to correct me on my ignorance, that's the main reason why we
don't support those properly

Cheers,
- Marc-Andre

Post by Seiji T

Post by Seiji T
Dear all,
I am trying to get 109 Japanese Keyboard (*1) to work with freerdp

without

Post by Seiji T
success.

I guess a part of the real could be that the FreeRDP settings for
kbd_type and kbd_subtype and kbd_fn_keys always are 0 when xfreerdp
sends Client Core Data in gcc_write_client_core_data .
That is according to http://msdn.microsoft.com/en-us/library/cc240510
not valid, and for japanese keyboards you might have to use keyboardType
7. That could in principle also change the rdp scan codes completely.
I don't know if correct values for these settings can be determined from
X (or windows) information somehow.
If mstsc from windows works correctly then you could try to dump and
analyze what it sends so we know how we could make it work.
/Mads
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Freerdp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

[Marc-André Moreau]

Ok, just read more of the original info that was given, here's what I think:

scancodes are normally hardware-specific, and RDP uses scancodes over the
network. Those scancodes are indeed always the same for the single keyboard
type which we're currently using (the generic IBM keyboard type). Since CJK
languages likely require that the keyboard type is changed (different
keyboard type id) my guess is that scancodes are no longer the same for
this different keyboard type.

This means we would likely have to write a different scancode map for the
Japanese keyboard type, to be used instead of the current one when a CJK
language is in use.

On Thu, Mar 22, 2012 at 4:40 PM, Marc-André Moreau <

Post by Marc-André Moreau
I have never tried making any of the CJK languages work due to lack of
knowledge regarding those. There is indeed significant differences in the
way those need to be handled, we need to pass an IME file along with a
different keyboard type I believe.
If you have general information on how those keyboards work, it would
help. If I understood correctly words are written phonetically and the IME
would suggest a possible kanji for it, which you can accept with a special
key?
I honestly don't know that much about Japanese and CJK input methods, I
guess that for Japanese hiraganas and katakanas could be used for typing in
words phonetically and then replace them with a kanji if necessary.
Feel free to correct me on my ignorance, that's the main reason why we
don't support those properly
Cheers,
- Marc-Andre

Post by Seiji T

Post by Seiji T
Dear all,
I am trying to get 109 Japanese Keyboard (*1) to work with freerdp

without

Post by Seiji T
success.

I guess a part of the real could be that the FreeRDP settings for
kbd_type and kbd_subtype and kbd_fn_keys always are 0 when xfreerdp
sends Client Core Data in gcc_write_client_core_data .
That is according to http://msdn.microsoft.com/en-us/library/cc240510
not valid, and for japanese keyboards you might have to use keyboardType
7. That could in principle also change the rdp scan codes completely.
I don't know if correct values for these settings can be determined from
X (or windows) information somehow.
If mstsc from windows works correctly then you could try to dump and
analyze what it sends so we know how we could make it work.
/Mads
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Freerdp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

[Seiji T]

Marc-Andre,

Thanks for the comment.

I am going to try to explain it to the best of my knowledge. Please
bear with me that I don't have deep knowledge of keyboards or
programming for that matter. Also I have no idea for what goes on in
Chinese and Korean keyboards/IME.

we need to pass an IME file along with a different keyboard type I
believe.

[Seiji T]

Mads,

As you have stated, kbd_* were the cause of the problem (Windows RDP
client not mapping scancode 0x7d correctly to vk_code OEM_5). Thanks
for pointing this out.

My colleague checked the values for kbd_* in rdesktop and by changing
these values in FreeRDP, pressing the "\|" keycap resulted in "\" being
shown on the RDP server (as it should). Also confirmed with YAMY that
the RDP server received scancode "0x7D" (as it should) and Windows
mapped this to vk_code "OEM_5" (as it should).

We're in the process of checking other keycaps but in the meantime, I
would like to discuss how we should merge these changes into the main
source.

Attached is the patch against the current source. We needed a quick way
to figure out the problem and therefore it cannot be applied to the
source. If you did, it would most likely break the US keyboard layout.
So how should we merge these changes to the main source?

Regards,
Seiji Tokunaga

Post by Seiji T
Dear all,
I am trying to get 109 Japanese Keyboard (*1) to work with freerdp without
success.

I guess a part of the real could be that the FreeRDP settings for kbd_type
and kbd_subtype and kbd_fn_keys always are 0 when xfreerdp sends Client Core
Data in gcc_write_client_core_data .
That is according to http://msdn.microsoft.com/en-us/library/cc240510 not
valid, and for japanese keyboards you might have to use keyboardType 7. That
could in principle also change the rdp scan codes completely.
I don't know if correct values for these settings can be determined from X
(or windows) information somehow.
If mstsc from windows works correctly then you could try to dump and analyze
what it sends so we know how we could make it work.
/Mads

[Seiji T]

Just realized attachment is not allowed. Here is the patch, I meant to
attach in the previous email.

--BEGIN--
diff --git a/libfreerdp-core/gcc.c b/libfreerdp-core/gcc.c
index 01ed01a..c8014cf 100644
--- a/libfreerdp-core/gcc.c
+++ b/libfreerdp-core/gcc.c
@@ -659,9 +659,12 @@ void gcc_write_client_core_data(STREAM* s,
rdpSettings* settings)
stream_write_zero(s, 32 - clientNameLength - 2);
xfree(clientName);

- stream_write_uint32(s, settings->kbd_type); /* keyboardType */
- stream_write_uint32(s, settings->kbd_subtype); /* keyboardSubType */
- stream_write_uint32(s, settings->kbd_fn_keys); /* keyboardFunctionKey */
+ //stream_write_uint32(s, settings->kbd_type); /* keyboardType */
+ //stream_write_uint32(s, settings->kbd_subtype); /* keyboardSubType */
+ //stream_write_uint32(s, settings->kbd_fn_keys); /* keyboardFunctionKey */
+ stream_write_uint32(s, 7); /* keyboardType */
+ stream_write_uint32(s, 2); /* keyboardSubType */
+ stream_write_uint32(s, 12); /* keyboardFunctionKey */

stream_write_zero(s, 64); /* imeFileName */

diff --git a/libfreerdp-locale/keyboard_layout.c
b/libfreerdp-locale/keyboard_layout.c
index ff2ca53..240233f 100644
--- a/libfreerdp-locale/keyboard_layout.c
+++ b/libfreerdp-locale/keyboard_layout.c
@@ -691,7 +691,7 @@ const uint32 VIRTUAL_KEY_CODE_TO_RDP_SCANCODE_TABLE[256] =
0x00,
0x00,
0x1A, /* VK_OEM_4 */
- 0x2B, /* VK_OEM_5 */
+ 0x7D, /* VK_OEM_5 */
0x1B, /* VK_OEM_6 */
0x28, /* VK_OEM_7 */
0x1D, /* VK_OEM_8 */
diff --git a/libfreerdp-locale/keyboard_xkb.c b/libfreerdp-locale/keyboard_xkb.c
index 91d2ecf..6a6ccc4 100644
--- a/libfreerdp-locale/keyboard_xkb.c
+++ b/libfreerdp-locale/keyboard_xkb.c
@@ -257,7 +257,7 @@ VIRTUAL_KEY_CODE_TO_XKB_KEY_NAME
VIRTUAL_KEY_CODE_TO_XKB_KEY_NAME_TABLE[256] =
{ 0, "", "" },
{ 0, "", "" },
{ VK_OEM_4, "AD11", "" }, /* VK_OEM_4 */
- { VK_OEM_5, "BKSL", "" }, /* VK_OEM_5 */
+ { VK_OEM_5, "AE13", "" }, /* VK_OEM_5 */
{ VK_OEM_6, "AD12", "" }, /* VK_OEM_6 */
{ VK_OEM_7, "AC11", "" }, /* VK_OEM_7 */
{
--END--

Post by Seiji T
Mads,
As you have stated, kbd_* were the cause of the problem (Windows RDP
client not mapping scancode 0x7d correctly to vk_code OEM_5). Thanks
for pointing this out.
My colleague checked the values for kbd_* in rdesktop and by changing
these values in FreeRDP, pressing the "\|" keycap resulted in "\" being
shown on the RDP server (as it should).  Also confirmed with YAMY that
the RDP server received scancode "0x7D" (as it should) and Windows
mapped this to vk_code "OEM_5" (as it should).
We're in the process of checking other keycaps but in the meantime, I
would like to discuss how we should merge these changes into the main
source.
Attached is the patch against the current source. We needed a quick way
to figure out the problem and therefore it cannot be applied to the
source. If you did, it would most likely break the US keyboard layout.
So how should we merge these changes to the main source?
Regards,
 Seiji Tokunaga

Post by Seiji T
Dear all,
I am trying to get 109 Japanese Keyboard (*1) to work with freerdp without
success.

I guess a part of the real could be that the FreeRDP settings for kbd_type
and kbd_subtype and kbd_fn_keys always are 0 when xfreerdp sends Client Core
Data in gcc_write_client_core_data .
That is according to http://msdn.microsoft.com/en-us/library/cc240510 not
valid, and for japanese keyboards you might have to use keyboardType 7. That
could in principle also change the rdp scan codes completely.
I don't know if correct values for these settings can be determined from X
(or windows) information somehow.
If mstsc from windows works correctly then you could try to dump and analyze
what it sends so we know how we could make it work.
/Mads

[Mads Kiilerich]

Hi

I assume you are using XKBFILE? (Testing without XKBFILE could perhaps
be relevant too, but that will probably reveal other issues so let's
forget that for now.)

Is the keyboard layout detected correctly or do you specify it with -k?
Are you using 0x00000411 or 0xE0010411? Why and why not?

Could keyboardType and keyboardSubType in principle be determined
automatically based on the keyboardLayout code? Or do we need a way to
specify them? Or do you have any idea how they could be detected on an X
system?


A general comment to your analysis: All keyboard layout processing is
usually done on the RDP server side based on some kind of key location
"scan codes" independent of which symbol is printed on the key and how
it should be processed. Local handling of layouts on the client side is
thus not relevant for xfreerdp. The client do however tell the server
which keyboard layout it recommends using ... but IIRC the server only
uses it when creating a new session, not when connecting to an existing
session. I have found it convenient to enable multiple layouts in the
servers configuration so it shows a keyboard layout indicator.

I take from your analysis that the key known by X as "AE13" should be
sent as 0x7D over the protocol.

A redefinition of VK_OEM_5 will however break other keyboard layouts.
The existing FreeRDP code is in my opinion unfortunate. VK codes can not
be used the way we try to use them; they are something else at a
different level.

I have some proposed changes in this area on
https://github.com/FreeRDP/FreeRDP/pull/520 .

/Mads

Post by Seiji T
Just realized attachment is not allowed. Here is the patch, I meant to
attach in the previous email.
--BEGIN--
diff --git a/libfreerdp-core/gcc.c b/libfreerdp-core/gcc.c
index 01ed01a..c8014cf 100644
--- a/libfreerdp-core/gcc.c
+++ b/libfreerdp-core/gcc.c
@@ -659,9 +659,12 @@ void gcc_write_client_core_data(STREAM* s,
rdpSettings* settings)
stream_write_zero(s, 32 - clientNameLength - 2);
xfree(clientName);
- stream_write_uint32(s, settings->kbd_type); /* keyboardType */
- stream_write_uint32(s, settings->kbd_subtype); /* keyboardSubType */
- stream_write_uint32(s, settings->kbd_fn_keys); /* keyboardFunctionKey */
+ //stream_write_uint32(s, settings->kbd_type); /* keyboardType */
+ //stream_write_uint32(s, settings->kbd_subtype); /* keyboardSubType */
+ //stream_write_uint32(s, settings->kbd_fn_keys); /* keyboardFunctionKey */
+ stream_write_uint32(s, 7); /* keyboardType */
+ stream_write_uint32(s, 2); /* keyboardSubType */
+ stream_write_uint32(s, 12); /* keyboardFunctionKey */
stream_write_zero(s, 64); /* imeFileName */
diff --git a/libfreerdp-locale/keyboard_layout.c
b/libfreerdp-locale/keyboard_layout.c
index ff2ca53..240233f 100644
--- a/libfreerdp-locale/keyboard_layout.c
+++ b/libfreerdp-locale/keyboard_layout.c
@@ -691,7 +691,7 @@ const uint32 VIRTUAL_KEY_CODE_TO_RDP_SCANCODE_TABLE[256] =
0x00,
0x00,
0x1A, /* VK_OEM_4 */
- 0x2B, /* VK_OEM_5 */
+ 0x7D, /* VK_OEM_5 */
0x1B, /* VK_OEM_6 */
0x28, /* VK_OEM_7 */
0x1D, /* VK_OEM_8 */
diff --git a/libfreerdp-locale/keyboard_xkb.c b/libfreerdp-locale/keyboard_xkb.c
index 91d2ecf..6a6ccc4 100644
--- a/libfreerdp-locale/keyboard_xkb.c
+++ b/libfreerdp-locale/keyboard_xkb.c
@@ -257,7 +257,7 @@ VIRTUAL_KEY_CODE_TO_XKB_KEY_NAME
VIRTUAL_KEY_CODE_TO_XKB_KEY_NAME_TABLE[256] =
{ 0, "", "" },
{ 0, "", "" },
{ VK_OEM_4, "AD11", "" }, /* VK_OEM_4 */
- { VK_OEM_5, "BKSL", "" }, /* VK_OEM_5 */
+ { VK_OEM_5, "AE13", "" }, /* VK_OEM_5 */
{ VK_OEM_6, "AD12", "" }, /* VK_OEM_6 */
{ VK_OEM_7, "AC11", "" }, /* VK_OEM_7 */
{
--END--

Post by Seiji T
Mads,
As you have stated, kbd_* were the cause of the problem (Windows RDP
client not mapping scancode 0x7d correctly to vk_code OEM_5). Thanks
for pointing this out.
My colleague checked the values for kbd_* in rdesktop and by changing
these values in FreeRDP, pressing the "\|" keycap resulted in "\" being
shown on the RDP server (as it should). Also confirmed with YAMY that
the RDP server received scancode "0x7D" (as it should) and Windows
mapped this to vk_code "OEM_5" (as it should).
We're in the process of checking other keycaps but in the meantime, I
would like to discuss how we should merge these changes into the main
source.
Attached is the patch against the current source. We needed a quick way
to figure out the problem and therefore it cannot be applied to the
source. If you did, it would most likely break the US keyboard layout.
So how should we merge these changes to the main source?
Regards,
Seiji Tokunaga

Post by Seiji T
Dear all,
I am trying to get 109 Japanese Keyboard (*1) to work with freerdp without
success.

I guess a part of the real could be that the FreeRDP settings for kbd_type
and kbd_subtype and kbd_fn_keys always are 0 when xfreerdp sends Client Core
Data in gcc_write_client_core_data .
That is according to http://msdn.microsoft.com/en-us/library/cc240510 not
valid, and for japanese keyboards you might have to use keyboardType 7. That
could in principle also change the rdp scan codes completely.
I don't know if correct values for these settings can be determined from X
(or windows) information somehow.
If mstsc from windows works correctly then you could try to dump and analyze
what it sends so we know how we could make it work.
/Mads

------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Freerdp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freerdp-devel