Make a Japanese Mac Keyboard Behave Correctly Through Windows RDP into Ubuntu XRDP

The confusing part of remote keyboard problems is that they often look like a single setting, but they are usually a chain.

In my case the real path was:

  • Japanese Mac keyboard
  • remote-control app into a Windows machine
  • Windows App / RDP into Ubuntu
  • xrdp on Ubuntu
  • an X11 desktop inside the XRDP session

Windows was already usable for Japanese typing. Terminal and Sublime Text on Ubuntu could also accept Japanese and Chinese input. But the Ubuntu XRDP desktop still felt like a plain us / pc105 keyboard in the places where the physical key positions mattered.

The fix was not to change the whole Ubuntu machine globally. The fix was to make only the XRDP session use the closest built-in Apple Japanese keyboard profile.

First: accept what Windows can and cannot do

Windows does not have a macOS-style setting that says “this physical keyboard is a Japanese Mac keyboard”.

The practical Windows side is:

  • Add Japanese in Windows language settings.
  • Use the Japanese keyboard / Microsoft IME.
  • Remove or deprioritize US if Windows keeps switching back.
  • Use Advanced keyboard settings when the wrong input method keeps returning.

Useful Windows commands:

Start-Process 'ms-settings:regionlanguage'
Start-Process 'control.exe' -ArgumentList '/name Microsoft.Language /page pageAdvanced'

This can make normal Japanese typing work on Windows. It does not guarantee that Mac-specific keys such as Kana and Eisu are transmitted perfectly through every remote-control app. If the remote app does not forward those keys cleanly, Ubuntu cannot recover the exact original hardware event later.

Then fix the Ubuntu XRDP side

On the Ubuntu side, the problem was visible in the keyboard state:

model:  pc105
layout: us

For a Japanese Apple keyboard, Ubuntu already ships a better XKB profile:

model:   applealu_jis
layout:  jp
variant: mac

That is the important line. It tells the X11 desktop inside XRDP to interpret the incoming keyboard as an Apple Aluminium JIS keyboard using the Japanese Macintosh variant.

You can test it immediately inside the XRDP session:

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

Expected result:

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

If you need to apply it from SSH to a live XRDP display, use the active display number:

DISPLAY=:10.0 XAUTHORITY="$HOME/.Xauthority" \
  setxkbmap -model applealu_jis -layout jp -variant mac

Your display may be :10.0, :11.0, or another XRDP display.

Make it persistent, but only for XRDP

I do not recommend switching the whole machine globally unless every local console, VNC session, and desktop path should become Japanese Mac layout.

For this setup, the safer solution is an XRDP-only hook in ~/.xsessionrc:

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; then
  if ! pgrep -u "$(id -u)" -x ibus-daemon >/dev/null 2>&1; then
    ibus-daemon -drx >/tmp/ibus-xrdp.log 2>&1 &
  fi
fi

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

This keeps the older CJK input fix and adds the Apple JIS keyboard override only when the session is an XRDP session.

No full reboot is required. For persistence testing, log out of the XRDP desktop and reconnect.

CJK input is a separate layer

Keyboard layout and input methods are related, but they are not the same thing.

If Japanese or Chinese input works in Terminal but fails in Chrome, Firefox, or Typora, check the IBus layer too. For this machine, the useful input stack included:

  • Japanese via ibus-mozc
  • Chinese Pinyin via libpinyin
  • Chinese Wubi via table:wubi-jidian86
  • IBus environment variables exported before GUI apps start

The persistent part is the same ~/.xsessionrc block above:

export GTK_IM_MODULE=ibus
export QT_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export CLUTTER_IM_MODULE=ibus

The key lesson is that browser and Electron apps often need the IME environment to exist when the app starts. If you fix IBus after Chrome or Typora is already running, restart those apps or reconnect the XRDP session.

Why not edit XRDP globally?

/etc/xrdp/xrdp_keyboard.ini may already know that Japanese RDP layout IDs map to jp. In this case, XRDP was not completely missing Japanese support. The mismatch was the XKB model and variant inside the desktop session.

Using setxkbmap in the session is less invasive:

  • It does not affect local console behavior.
  • It does not disturb VNC.
  • It is easy to remove.
  • It documents the exact remote path assumption.

If this still leaves one or two special keys wrong, do not keep changing global keyboard settings blindly. Capture the actual keycode in the XRDP session and remap only that specific key.

Checklist

For this Mac -> Windows -> RDP -> Ubuntu chain:

  1. Make Windows Japanese input usable first.
  2. In Ubuntu XRDP, test setxkbmap -model applealu_jis -layout jp -variant mac.
  3. Put the XRDP-only setxkbmap block in ~/.xsessionrc.
  4. Keep IBus environment variables in the same file for Chrome, Firefox, Typora, and other GUI apps.
  5. Reconnect XRDP once.
  6. Only if Kana or Eisu still fails, create a targeted key remap for the actual forwarded keycode.

This is the stable mental model: Windows handles its own IME and layout; XRDP forwards a remote keyboard state; Ubuntu must still choose the correct XKB model, layout, and variant for the desktop session.

Leave a Reply