Wrong keyboard layout in remote app mode

[FrnchFrgg]

Describe the bug

When connecting to Windows 11 Pro "full session" with command line xfreerdp3 /v:host the keyboard layout is correctly obeyed and translated by xfreerdp (the windows is setup to use French AZERTY and the linux client also uses French AZERTY).

But when connecting to a single application as in xfreerdp3 /v:host /app:program:explorer.exe then the keyboard layout becomes QWERTY, ignoring both the local (client) keyboard layout but also the default layout set on the Windows machine.

Options like /kbd:layout:<id> do not fix the problem. /kbd:unicode fixes the letters but CTRL+<key> combos are no longer detected. (while reading bug reports I thought that using /kbd:unicode in desktop/session mode would also break CTRL+<key> combos but in my tests it did not)

To Reproduce

1. Run podman run -it -p 3389:3389/tcp -p 3389:3389/udp -p 8006:8006 --device=/dev/kvm --cap-add NET_ADMIN --stop-timeout 120 --env VERSION=win11 --env LANGUAGE=French -v ./toto:/toto docker.io/dockurr/windows to get a French-configured windows
2. While waiting for it to be up and running, add and select the French default keyboard in your desktop environment of choice. [EDIT: Not needed, on a machine that is not in AZERTY I get the same inconsistency]
3. Run xfreerdp /v:localhost /u:Docker /p: and notice that the server keyboard layout is correctly used
4. Run xfreerdp /v:localhost /u:Docker /p: /app:program:explorer.exe and notice the keyboard is now QWERTY [EDIT: which is neither the client layout nor the server layout]

Expected behavior The keyboard behaviour should be the same in step 4 and 5.

Application details

• FreeRDP version This is FreeRDP version 3.5.1 (n/a) (also present in 3.6.3 from Debian Testing)
• Command line used (see above)
• Output of `xfreerdp /buildconfig

  Build configuration: BUILD_TESTING=OFF WINPR_HAVE_AIO_H=1 WINPR_HAVE_EXECINFO_BACKTRACE=1 WINPR_HAVE_EXECINFO_BACKTRACE_SYMBOLS=1 WINPR_HAVE_EXECINFO_BACKTRACE_SYMBOLS_FD=1 WINPR_HAVE_EXECINFO_HEADER=1 WINPR_HAVE_FCNTL_H=1 WINPR_HAVE_GETLOGIN_R=1 WINPR_HAVE_GETPWUID_R=1 WINPR_HAVE_INTTYPES_H=1 WINPR_HAVE_POLL_H=1 WINPR_HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 WINPR_HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIBS= WINPR_HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL=1 WINPR_HAVE_STDBOOL_H=1 WINPR_HAVE_STDINT_H=1 WINPR_HAVE_STRNDUP=1 WINPR_HAVE_SYSLOG_H=1 WINPR_HAVE_SYS_EVENTFD_H=1 WINPR_HAVE_SYS_FILIO_H= WINPR_HAVE_SYS_SELECT_H=1 WINPR_HAVE_SYS_SOCKIO_H= WINPR_HAVE_SYS_TIMERFD_H=1 WINPR_HAVE_TM_GMTOFF=1 WINPR_HAVE_UNISTD_H=1 WINPR_HAVE_UNWIND_H=1 WITH_AAD=ON WITH_ABSOLUTE_PLUGIN_LOAD_PATHS=ON WITH_ADD_PLUGIN_TO_RPATH=OFF WITH_ALSA=ON WITH_BINARY_VERSIONING=ON WITH_CAIRO=OFF WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLANG_FORMAT=OFF WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CLIENT_SDL=ON WITH_CLIENT_SDL_AVAILABLE=1 WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_CODECS=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_EVENTS=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SCHANNEL=OFF WITH_DEBUG_SDL_EVENTS=OFF WITH_DEBUG_SDL_KBD_EVENTS=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=ON WITH_DSP_FFMPEG_AVAILABLE=1 WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=ON WITH_FREERDP_DEPRECATED=OFF WITH_FREERDP_DEPRECATED_COMMANDLINE=OFF WITH_FUSE=ON WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=ON WITH_ICU=ON WITH_INTERNAL_MD4=OFF WITH_INTERNAL_MD5=OFF WITH_INTERNAL_RC4=OFF WITH_JPEG=ON WITH_KERBEROS=ON WITH_KRB5=ON WITH_KRB5_NO_NTLM_FALLBACK=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBRESSL=OFF WITH_LODEPNG=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_NATIVE_SSPI=OFF WITH_NEON=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSC_PKCS11_LINKED=OFF WITH_OPENSSL=ON WITH_OPUS=ON WITH_OSS=ON WITH_PCSC=ON WITH_PKCS11=ON WITH_PLATFORM_SERVER=ON WITH_POLL=ON WITH_PROFILER=OFF WITH_PROXY=ON WITH_PROXY_APP=ON WITH_PROXY_EMULATE_SMARTCARD=OFF WITH_PROXY_MODULES=ON WITH_PULSE=ON WITH_RDTK=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SDL_IMAGE_DIALOGS=ON WITH_SDL_LINK_SHARED=ON WITH_SERVER=ON WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SHADOW=ON WITH_SMARTCARD_EMULATE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SMARTCARD_PCSC=ON WITH_SOXR=OFF WITH_SSE2=OFF WITH_SWSCALE=ON WITH_SYSTEMD=ON WITH_THIRD_PARTY=OFF WITH_UNICODE_BUILTIN=OFF WITH_URIPARSER=ON WITH_VAAPI=OFF WITH_VAAPI_AVAILABLE=1 WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_VERBOSE_WINPR_ASSERT=OFF WITH_VIDEO_FFMPEG=ON WITH_VIDEO_FFMPEG_AVAILABLE=1 WITH_WAYLAND=ON WITH_WEBVIEW=OFF WITH_WINPR_DEPRECATED=OFF WITH_WINPR_TOOLS=ON WITH_WINPR_UTILS_IMAGE_JPEG=ON WITH_WINPR_UTILS_IMAGE_PNG=ON WITH_WINPR_UTILS_IMAGE_WEBP=ON WITH_WIN_CONSOLE=ON WITH_X11=ON WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XV=ON
  Build type:          RelWithDebInfo
  CFLAGS:              -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wpedantic -Wno-padded -Wno-cast-align -Wno-declaration-after-statement -fPIC -Wall -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -g -fno-omit-frame-pointer
  Compiler:            GNU, 12.2.0
  Target architecture: x64

  • OS: Linux
  • Version/Distribution: Debian 12
  • Architecture: amd64:

[akallabeth]

are you sure the keyboard layout is set to french in that case server side? The local layout is ignored (we extract the scancodes from the keys pressed with some magic), only the server side layout is relevant. in both cases the same layout id is sent to the server, but with remote-app there is usually a small window where you can set the current active keyboard layout should you have multiple installed

[FrnchFrgg]

I am totally certain that the keyboard is set to french server side, and without remote-app I get french layout (even if my keyboard is not in french AZERTY client-side). To sum up:

• The keyboard uses the french AZERTY layout without remote-app, regardless of which layout is active client-side (this is normal AFAIU)
• The keyboard uses some QWERTY layout (seems en-US to me) within remote-app, regardless of which layout is active client-side
• /kbd options to change advertised layout seem to do nothing for the remote-app case which stays in QWERTY, except
• /kbd:unicode which is taken into account but has the known caveats

EDIT: I do not see the language bar or similar in remote-app case, nor in desktop mode (in the latter case this is normal since the client and server layout is the same.

EDIT2: The windows server has only french AZERTY set up. This is not a case of a wrong default selection in the case of multiple installed layouts.

[akallabeth]

@FrnchFrgg I´ve just tested this. It is working if you start a new session on the server. If you reconnect to an existing session the last set value is used and the layout you send is ignored.

Try to log out all your server side sessions and connect again. closing as resolved, ping me if it still does not work.

[FrnchFrgg]

I'll try soon. Two questions that may hint at a bug nevertheless:

1. Do I need to explicitly send a French layout with /kbd or not ? Why, if the server default is French ? I never sent any layout setting until I noticed a problem (and at the time both client and server used AZERTY).
2. Why is the behavior different between the remote-app and the desktop case ?

[akallabeth]

@FrnchFrgg

1. you need to send something, there is no way to send nothing.
2. it is up to the server to do something with this, so ask microsoft ;)

[FrnchFrgg]

there is no way to send nothing.

What I meant is « why do I need to use the /kbd:layout:0x000040C option if this is the server default layout ? ». Maybe xfreerdp3 is sending something anyway if I do not use that option.

I just tested and if I always connect using the above option then indeed the layout is correct in both desktop and remote-app modes, but that was using a windows 10 image (same docker, but with win10 setting). I'll have access to a windows 11 later.

[akallabeth]

there is no way to send nothing.

What I meant is « why do I need to use the /kbd:layout:0x000040C option if this is the server default layout ? ». Maybe xfreerdp3 is sending something anyway if I do not use that option.

it always sends the detected keyboard layout. if that is different from what you expect (or want a different layout remotely) you need to add /kbd option