Freerdp: Option to use the local keyboard layout

[tobia]

The manual says:

Keyboard mapping is done on the remote end, so the local keyboard layout is ignored. Instead, a Windows keyboard layout id is provided at connection time to tell the server which keyboard layout to use.

This poses a problem in many cases, for example when the local keyboard layout is not present on the remote side (GNU/Linux supports many more locales and specialized keyboard layouts than Windows) or when there are issues with the RDP protocol that prevent setting the remote keyboard ID.

It would be useful to have a "local keyboard" option as a fallback, where the user can tell FreeRDP what the remote keyboard layout is supposed to be and the software translates local symbols to remote scan codes, according to that layout.

For example, if such an option was enabled and set to US keyboard, then:

• a keyboard event that generates "A" in the local keyboard layout would be read by FreeRDP as the symbol "A", ignoring the original scan code;
• FreeRDP would translate it into a scan code of (say) 0x1E, based on the chosen remote layout (US)
• the scan code 0x1E would be sent through RDP.

Therefore, to the remote OS it would look like the "A" key of an US keyboard was pressed, when in reality a completely different key might have generated the "A" symbol in the local keyboard layout.

Does this make sense? Would it be technically feasible?

[bmiklautz]

@tobia just to make sure are you hitting a real problem with your setup?

[tobia]

In my case I wouldn't say problem, it's just a nuisance.

I use the Programmer Dvorak keyboard layout (included in X11 as the "dvp" variant of "us" layout) and apparently there's no way to make it go through FreeRDP, it always ignores my layout and uses Windows keyboard layouts.

I figured this might be a problem for people using a lot of the other locales and layouts available on X11.

I don't know if this is a "feature" of RDP, but in general I think it would be more useful to keep the local keyboard layout, instead of sending raw scan codes. For example, SSH has no concept of "remote keyboard layout", thankfully.

[tsdh]

@bmiklautz This is in fact the single problem why I keep on using rdesktop instead of freerdp.

I use a German Dvorak Type II layout (which is available by default on Linux/X11 but not Windows). When I connect to some remote Windows machine, I think I get a US Dvorak layout where, e.g., the T and the R, are on different positions than in the German variant. I can hardly type anything.

With rdesktop and without any special option, I can just type my usual local layout which seems to get translated transparently.

[hardening]

The supported RDP layout are there:
https://technet.microsoft.com/en-us/library/cc766503%28WS.10%29.aspx

Can you find yours here ?

[hardening]

it would be interesting to see the output of setxkbmap -print

[tsdh]

@hardening Nope, it's not on that list. There's just US Dvorak and US Dvorak for right hand. xfreerdp /kbd-list list also "United States-Dvorak for left hand" and "United States-Programmer Dvorak", so it seems freerdp already supports more layouts than those on this list.

And here's the setxkbmap -print output:

% setxkbmap -print
xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(qwertz)" };
    xkb_types     { include "complete"  };
    xkb_compat    { include "complete"  };
    xkb_symbols   { include "pc+de(dvorak)+us:2+inet(evdev)+ctrl(nocaps)"   };
    xkb_geometry  { include "pc(pc104)" };
};

As you can see, I also made CapsLock a third Ctrl (Emacs user ;-)). However, I can easily live without that on remotes. With rdesktop, CapsLock also behaves as CapsLock on remotes.

[metalight]

+1
This is number 1 issue with FreeRDP!

My keymap layout is defined with xmodmap.
It is a customized "danish-ized" Dvorak layout - it does not exist anywhere as a standard, it is not "danish dvorak".

I have been using this for 12 years.
It is completely ignored by FreeRDP.

I would love to kick the aging and glitching rdesktop - and start using FreeRDP, but this is simply not an option for me now, as I would have to learn a (for me) sub-optimal "standard keymap" first.

[huguesdk]

Same here. I’m using a customized version of the French Dvorak layout called BÉPO with some remapped modifiers. It works correctly with rdesktop.

[ensc]

alternatively: is there some way to define own layouts? (Very) old maillist postings mention definitions in /usr/share/freerdp/keymaps but this directory does not seem to exist anymore.

[qralston]

I swap my Ctrl and Caps Lock keys in my keyboard layout. When I use rdesktop, it obeys the swapped keys, but xfreerdp does not.

I can appreciate, from a technical perspective, that xfreerdp's behavior may be more correct. I get it. But simply put: _I don't care_. From my perspective—the user perspective; the most important perspective—xfreerdp's keyboard behavior is broken, and rdesktop's is not.

I can also appreciate that xfreerdp is a better RDP client than rdesktop in almost every way. I would like to switch from rdesktop to xfreerdp. But the broken keyboard handling is a dealbreaker.

Surely there must be some way to resolve this long-standing issue. How can we help?

[cizra]

It's mighty unlikely that the FreeRDP project will accept my contribution, on the grounds of insufficient humility towards PEOPLE WHO LOVE TO USE ALL CAPS, but here's a PR with a fix:

https://github.com/FreeRDP/FreeRDP/pull/5301

[akallabeth]

@cizra the reason is more like you break an existing working implementation because your use case is not supported.
The way I see it you have 2 options:

1. Implement a keyboard handling similar to the one of aFreeRDP and use the unicode input path.
   
   
   
   • Does not allow switch layouts remotely
   
   
   • Limited support for target operating systems (you need to test which ones work correctly)
   
   
2. Implement a reverse mapping similar to the one used by rdesktop
   
   
   
   • quite error prone and really a lot of work
   
   

Either way, it is more than a code change of 1 line ;)
Pull requests welcome, but this kind of mapping is not my use case and I simply don´t have the time to test this.

[cizra]

It works for me, so I'll just continue rebasing my fork. Indeed it breaks caps lock but it's only useful for toggling run in FPSes anyway.

[mojomojomojo]

In my case, I have caps as another ctrl on both the local linux machine and on the remote Windows machine (kb scan code map). Xfreerdp treats it like a caps lock. )-8

[ensc]

Here, meta and alt are swapped; left ctrl ist "mode switch" (e.g. used to create umlauts), shift + left ctrl is caps lock. Works perfectly with rdesktop but is a blocker for using xfreerdp.

[kris7t]

I am using a custom Xkb layout (US english keyboard + Caps Lock as a thrid-level modifier + accented characters from the languages I usually write in. Hence, the existing approach of letting Windows take care of the keyboard layout is quite inconvenient, and, as far as I know, reverse mapping a la rdesktop is not sufficient (there is no WIndows keyboard layout with precisely the symbols I want). Hence, I would be quite interested in using the Unicode input path. How would one go about implementing such a feature? Any pointers to source files worth looking at?

[akallabeth]

@kris7t Feel free to experiment.
Pointers here:

• include/freerdp/input.h contains the relevant functions
• freerdp_input_send_keyboard_event and freerdp_input_send_keyboard_event_ex send scancodes (= the codes a key generates when pressed)
• freerdp_input_send_unicode_keyboard_event sends unicode events (UCS2, 16 bit only)

Sending everything from local symbols is quite easy, only issue we have (and why we never moved forwared) is that windows requires certain stuff to be sent as scancode input (most system key combinations et al)

[kris7t]

@akallabeth Thanks! I'll take a look when I'll have some free time. :)

[lemoinem]

Wouldn't something simpler be easier to implement in the mean time? something like an option with a pair of keys for the map? map key1 to newkey1, key2 to newkey2, etc.?

It wouldn't break anyone not using it and definitely solve the issue of "my caps lock is a control and I want my Pause/Break to be an additional escape or something".

It's not a replacement to @kris7t's solution (which I like quite a bit as well, but solves a different problem, I think).

It's something that's been asked for a long time (at least 2011) and offering the user a way to customize their keyboard would probably help a lot of people, without bothering anyone not caring about that.)

@akallabeth would you be open with this kind of PR? If yes, I'll try to have a look at it.

[itkfm]

GNU/Linux supports many more locales and specialized keyboard layouts than Windows

My biggest problem with this is that Windows will then default to the EN/US layout which is sometimes pretty incompatible to your local layout.
For example, if you're using let's say at-nodeadkeys (which is a QWERTZ layout), you'll get EN/US on Windows (a QWERTY layout; pretty different). This causes essential keystrokes to be completely different (e.g. \, : (actually almost all non alpha-numeric keys)),

[akallabeth]

@lemoinem that sounds a lot like you try to supply your own keymap (aka map local keys to scancodes) ;) as mentioned, pr welcome.

@itkfm have a look at the /kbd: option, that way you can tell the remote windows system which layout to use. (of course, these are only layouts supported by the remote windows system)

[itkfm]

@akallabeth doesn't seem to work here.
xfreerdp /kbd:0x00010407 -u USERNAME -d MYDOMAIN IP.ADD.RES.S still gives me EN/US in Windows. (German layout is installed, machine default and select-able in the taskbar, though.) Am I doing something wrong here?

[akallabeth]

@itkfm depends on your server os and client version (there have been some changes in newer windows versions that require a client update)