Caps Lock (incl. Apple's own Korean "한/A" key) no longer switches iPad's local Korean/English input — forces literal Caps Lock on macOS host instead
Environment
- Client: iPad, Jump Desktop for iOS (latest, Jump Desktop 10)
- Host: macOS, Jump Desktop Connect (latest)
- iPad has both English and Korean (2-Set Korean) keyboards installed
- iPadOS Settings > General > Keyboard > Hardware Keyboard > "Switch Languages using ⇪/A" is ON
- macOS host's input source is always kept fixed on English (ABC) during the session
How it used to work (previous Jump Desktop versions)
On the iPad's hardware keyboard, the Caps Lock key position is configured via iPadOS's own "Switch Languages using ⇪/A" feature as the Korean/English toggle for the iPad itself, not a literal Caps Lock.
When connected to a macOS host through Jump Desktop:
- The macOS host stayed fixed on English (ABC) input the entire time.
- Pressing Caps Lock only switched the iPad's own local keyboard language between Korean and English.
- The iPad's own IME composed the Hangul locally, and Jump Desktop simply relayed the already-composed text to the host.
- This worked perfectly and reliably in older Jump Desktop versions, with zero effect on the host's input source.
What happens now (Jump Desktop 10)
- Pressing Caps Lock on the iPad no longer switches the iPad's own local language at all while Jump Desktop is in the foreground.
- Instead, the key press is forwarded to the macOS host, forcing a literal Caps Lock (all-caps) state there.
- Result: inside a Jump Desktop session, the iPad's own Caps-Lock-based language switching is completely dead, with no way to control Korean/English input through the previous workflow.
Confirmed on Apple's own official Korean keyboard hardware, not just a custom setting
To rule out this being specific to a custom iPadOS configuration, I tested with a second iPad Pro using an official Apple Smart Keyboard Folio in the Korean layout — genuine Apple hardware, no third-party keyboard or remap involved.
On this Korean Smart Keyboard Folio, the key at the Caps Lock position is physically labeled "한/A" (Han/A) — Apple's own factory-standard key for switching Hangul/English on every Korean-layout Apple keyboard, out of the box, no configuration required.
Pressing "한/A" inside a Jump Desktop session produces the exact same regression: instead of switching the iPad's local language, it forces literal Caps Lock on the macOS host. So this isn't limited to a manually-enabled setting — it breaks Apple's own official Korean keyboard hardware in its default state, affecting any Korean iPad user with an official Apple Korean keyboard.
Technical evidence
I installed Karabiner-Elements on the macOS host purely for diagnostics and opened Karabiner-EventViewer while pressing Caps Lock / "한/A" on the iPad during an active session. Every other ordinary key is invisible to EventViewer, but Caps Lock specifically produces this:
unknown - Unsupported HID usage
from: Karabiner DriverKit VirtualHIDKeyboard 1.8.0
usage page: 8 (0x0008)
usage: 2 (0x0002)
integer value: 0 → 1
Per the USB HID Usage Tables spec, Usage Page 0x08 is the LED page, and Usage 0x02 is specifically "Caps Lock" (an On/Off Control indicator) — not a standard Keyboard Usage Page (0x07) key-down/key-up event.
This suggests Jump Desktop Connect now injects Caps Lock into macOS as a direct LED-page state assertion via a Karabiner DriverKit virtual keyboard device, rather than relaying a normal key press. I suspect this is a side effect of "Viewer: iOS: Fix Caps Lock not working with hardware keyboard" (v10.8.7 / Beta 3, 2026-03-23) — before that fix, Caps Lock presses apparently weren't captured by the Jump iOS app at all, which is why they passed through untouched to iPadOS's own system-level language-switch handler.
Because this is now a low-level state assertion rather than a discrete key event, it can't be intercepted by any remapping layer — not iPadOS's hardware keyboard remap, not macOS's Modifier Keys settings, and not even a Karabiner-Elements complex_modification rule keyed on key_code: caps_lock (which matches Keyboard Usage Page 0x07 events, not LED Page 0x08 assertions). All other ordinary keys are forwarded through a completely different path (likely CGEventPost, since Karabiner-EventViewer never sees them either), so there's no way to route around this via a substitute physical key — it's specifically the Caps Lock/한A position that gets hijacked, regardless of which physical key produces that signal.
Request
Given the team has been actively investing in Korean/CJK hardware keyboard support throughout the v10 cycle, I'd guess the Korean "한/A" key case (and the equivalent "Switch Languages using ⇪/A" behavior on any keyboard) simply wasn't part of the test matrix for the Caps Lock fix. Given how many Korean users this default hardware behavior affects, this feels like a higher-priority regression rather than an edge case.
For users relying on iPadOS's built-in per-keyboard Caps Lock language-switch feature while keeping the macOS host fixed on a single input source, could the team consider:
1. A setting to opt out of Caps Lock capture/forwarding on iOS, so it stays a purely local iPadOS function as before, or
2. Only capturing/forwarding Caps Lock when it isn't already being consumed by iPadOS's own language-switch feature, or
3. At minimum, a choice between "relay Caps Lock as a normal key event" vs "force host Caps Lock state."
If anyone else with a Korean (or other CJK) keyboard setup is seeing this, would appreciate a comment/vote here — happy to share logs or a screen recording if it helps the team track it down.
-
I'm experiencing the exact same issue. Pressing Caps Lock to switch between Korean and English on my iPad now toggles Caps Lock on the Mac instead. This makes typing in Korean through Jump Desktop very frustrating. Please restore the previous behavior or add an option to keep language switching local to the iPad.
-
I’m experiencing the same issue on my iPad with a Magic Keyboard Folio.
I also noticed that the actual input language seems to be completely determined by the iPad’s current input source. If the iPad is set to Korean, I can only type Korean even if I switch the Mac’s input source to ABC using Control + Space. Likewise, if the iPad is set to English, I can only type English even if the Mac is switched to Korean.
Since the 한/A (Caps Lock) key is now being forwarded to the Mac instead of switching the iPad’s input language, there is effectively no convenient way to switch between Korean and English while using Jump Desktop.
This worked perfectly before, so I hope the previous behavior can be restored soon.
-
Here is the temporary workaround.
1. While connected to the Mac through Fluid on the iPad, press Command + Space to open the iPad’s Spotlight.
2. With Spotlight open, press Caps Lock to switch between Korean and English.
3. Wait 1–2 seconds. A small pop-up with white text on a black background briefly appears in Jump Desktop, indicating the newly selected input source.
4. Dismiss Spotlight and return to Jump Desktop. Typing now works correctly in the language selected in Spotlight.In my testing, this works regardless of whether the remote Mac’s input source is set to ABC or Korean.
Please sign in to leave a comment.
Comments
5 comments