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 On 03/27/2012 10:08 AM, Seiji T wrote: > 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 ------------------------------------------------------------------------------ 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
