On Fri, May 15, 2009 at 10:18 PM, Peter Åstrand <astrand@cendio.se> wrote:
I'm referring to the g_keylayout variable in rdesktop, which defaults to 0x409, and is otherwise set by using the "map" keyword in keymap files. It is also sent in sec_out_mcs_data, under the section:

       /* Client information */
       out_uint16_le(s, SEC_TAG_CLI_INFO);

Yes, we're talking about the same thing.
This value tells the RDP server which Windows keyboard to install temporarily for the session.

(Why secondary? I think that if the keyboard LCID is different from the system's main one, it is installed IN ADDITION to the existing one, thus "secondary".)
 
This information tells the RDP server which keymap to use, ie how to interpret RDP scancodes.

Just to make it clear, the Windows Terminal Service doesn't use this value to interpret anything. It installs a keyboard layout for the system (just like you could do manually later, through the Control Panel) and then feeds the received scancodes (letting Windows do the translation to WM_CHARs).
 
When the XKB extension is not available, we should fall back to the existing facility (the one which uses rdesktop keymap files).

In other words: Lots of pain, no gain. If we can't get rid of the current implementation nor the keymaps, it's going to be a *lot* of work for basically no value.

I disagree. On XKB systems (most modern desktops), we won't use unreliable pregenerated keymaps anymore = gain. Otherwise, we still have the old fallback (at no additional devel cost to us) = no pain.