Japanese Mac Keyboard over Windows RDP to Ubuntu XRDP

A Japanese Mac keyboard can work normally on Windows and still behave like a US PC keyboard after another RDP hop into Ubuntu. The useful way to debug this is not to hunt for one global keyboard setting. Follow the key through each layer.

My path was:

  1. a Japanese Apple JIS keyboard;
  2. a remote-control app connected to Windows;
  3. Windows App / Remote Desktop connected to Ubuntu;
  4. xrdp and xorgxrdp on Ubuntu;
  5. an X11 desktop with IBus for Japanese and Chinese input.

Normal Japanese input already worked on Windows. Terminal and Sublime Text in the Ubuntu session could also accept Japanese and Chinese. The remaining problem was physical key placement: the XRDP desktop reported a plain pc105 / us keyboard instead of the closer Apple JIS model.

The fix was to test an Apple JIS XKB layout inside the XRDP session, then make that small change persistent only for XRDP.

Check the whole path before changing it

Run these commands in a terminal opened inside the Ubuntu XRDP desktop:

printf 'DISPLAY=%s\nXRDP_SESSION=%s\nXDG_SESSION_TYPE=%s\n' \
  "$DISPLAY" "${XRDP_SESSION:-}" "${XDG_SESSION_TYPE:-}"
setxkbmap -query
xrdp --version 2>/dev/null || true
ls -1 /etc/xrdp/xrdp_keyboard.* 2>/dev/null || true

A typical wrong state looks like this:

rules:      evdev
model:      pc105
layout:     us

Also inspect what XRDP received from the RDP client:

sudo journalctl -u xrdp --since today | grep -Ei 'keyboard|keymap|layout'
sudo grep -Ei 'keyboard|keymap|layout' /var/log/xrdp.log

The log matters because current XRDP keyboard handling starts from the keyboard type, subtype, and layout identifier sent by the client. Upstream XRDP includes Japanese layout IDs and a Macintosh subtype that selects the mac XKB variant. In a nested Mac → remote app → Windows → RDP path, however, the second hop may only see the keyboard identity reported by Windows. That is why the automatic result can be reasonable for Windows but wrong for the original physical keyboard.

Before using the values below, confirm that your Ubuntu installation provides them:

localectl list-x11-keymap-models | grep -Ex 'applealu_jis'
localectl list-x11-keymap-variants jp | grep -Ex 'mac'

Test the Apple JIS layout in the XRDP session

For an Apple aluminium Japanese keyboard, the useful XKB combination is:

model:    applealu_jis
layout:   jp
variant:  mac

Apply it to the current XRDP desktop:

setxkbmap -model applealu_jis -layout jp -variant mac
setxkbmap -query

The expected query result is:

rules:      evdev
model:      applealu_jis
layout:     jp
variant:    mac

Test the keys that were actually wrong before making anything persistent. xev is helpful when Kana, Eisu, backslash, yen, or another physical key still behaves unexpectedly:

xev -event keyboard

Press one problem key at a time and record its keycode and keysym. Close the small xev window when finished. A targeted observation is much safer than copying a machine-wide remap from a different keyboard.

setxkbmap applies to an X server. It is appropriate for the Xorg session normally created by xorgxrdp; it is not a general Wayland fix. If XDG_SESSION_TYPE says wayland, stop and diagnose that session rather than forcing this command.

Make the change persistent only for XRDP

First preserve the existing session file if it exists:

cp -a "$HOME/.xsessionrc" "$HOME/.xsessionrc.before-jis-xrdp" 2>/dev/null || true

Then add this block to ~/.xsessionrc:

if [ "${XRDP_SESSION:-}" = "1" ]; then
  export GTK_IM_MODULE=ibus
  export QT_IM_MODULE=ibus
  export XMODIFIERS=@im=ibus
  export CLUTTER_IM_MODULE=ibus

  if command -v ibus-daemon >/dev/null 2>&1 && \
     ! pgrep -u "$(id -u)" -x ibus-daemon >/dev/null 2>&1; then
    ibus-daemon -drx >"${XDG_RUNTIME_DIR:-/tmp}/ibus-xrdp.log" 2>&1 &
  fi

  if [ "${XDG_SESSION_TYPE:-x11}" = "x11" ] && \
     command -v setxkbmap >/dev/null 2>&1; then
    setxkbmap -model applealu_jis -layout jp -variant mac \
      >"${XDG_RUNTIME_DIR:-/tmp}/setxkbmap-xrdp.log" 2>&1
  fi
fi

Log out of the XRDP desktop and reconnect. A full Ubuntu reboot is not required.

The XRDP_SESSION guard is important. XRDP’s own startup script uses that variable when showing how to apply session-specific desktop settings. Without the guard, .xsessionrc may change other X11 sessions owned by the same user.

CJK input and physical key layout are different layers

XKB decides how physical keys are interpreted. IBus decides how typed keys become Japanese or Chinese text. Fixing one does not prove the other is correct.

For this setup, the input-method stack included:

  • Japanese through ibus-mozc;
  • Chinese Pinyin through libpinyin;
  • Chinese Wubi through table:wubi-jidian86;
  • the IBus environment variables exported before GUI applications start.

If Terminal accepts Japanese but Chrome, Firefox, or an Electron application does not, close and reopen that application after the IBus environment is present. Reconnecting the XRDP session is the cleanest test.

When not to edit XRDP globally

Do not start by replacing /etc/xrdp/xrdp_keyboard.ini, /etc/xrdp/xrdp_keyboard.toml, or the km-* files.

XRDP releases do not all use the same configuration format: newer upstream code uses TOML, while older packaged releases may still have INI files. The installed file and version are more reliable than a copied tutorial. A global keymap change also affects every matching XRDP connection, not only this user and keyboard.

Edit XRDP’s system mapping only when the log proves that the client layout is recognized incorrectly for every affected session and you can test a rollback. If XRDP reports the expected Japanese layout but only this Apple keyboard has misplaced keys, the user-session XKB override is the smaller change.

Roll back cleanly

If the result is worse, remove the added block and reconnect. If the backup was created and contained your complete previous file, restore it with:

cp -a "$HOME/.xsessionrc.before-jis-xrdp" "$HOME/.xsessionrc"

If there was no previous file, remove only the block you added. Do not overwrite other desktop or input-method settings that appeared later.

Short checklist

  1. Make Japanese input work on Windows first.
  2. Inspect setxkbmap -query and the XRDP keyboard log inside Ubuntu.
  3. Confirm applealu_jis and the jp / mac variant exist locally.
  4. Test the layout in the current XRDP session.
  5. Record any remaining special-key mismatch with xev.
  6. Put the guarded block in ~/.xsessionrc, then reconnect once.
  7. Keep global XRDP files unchanged unless the log proves a system-wide mapping fault.

That is the stable mental model: the outer remote app carries a physical keyboard into Windows, RDP reports a keyboard identity to XRDP, XKB maps physical keys in the Ubuntu X11 session, and IBus handles Japanese or Chinese composition.

Primary references

If the problem is larger than one keyboard—several remote machines, a relay, unclear network exposure, or no tested recovery path—the LazyRemote Network Fit Review shows the software-only USD 250 scope and a complete sample before its fit check.

Leave a Reply