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--

On Tue, Mar 27, 2012 at 4:33 PM, Seiji T <mlb...@gmail.com> wrote:
> 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
>
> On Fri, Mar 23, 2012 at 5:28 AM, Mads Kiilerich <m...@kiilerich.com> wrote:
>> n 03/21/2012 07:01 AM, Seiji T wrote:
>>>
>>> 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

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

Reply via email to