Weird behavior with Windows IME

[0x21D8]

mpv Information

mpv v0.40.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects 
 built on Sep  5 2025 15:11:06
libplacebo version: v7.354.0 (v7.351.0-67-g515da95-dirty)
FFmpeg version: n7.1.1-57-g1b48158a2
FFmpeg library versions:
libavcodec      61.19.101
libavdevice     61.3.100
libavfilter     10.4.100
libavformat     61.7.100
libavutil       59.39.100
libswresample   5.3.100
libswscale      8.3.100

Other Information

- Windows version: 20348.4297
- GPU model, driver and version: -
- Source of mpv: shinchiro
- Latest known working version: -
- Issue started after the following happened: -

Reproduction Steps

Not reproducible. Unique. The flag --input-ime=yes resolves the issue.

I also tested mpv v0.40.0-402-gaa2dad035 built on Oct 24 2025 00:07:02, and the problem persisted.

This is not exactly an mpv issue, but someone might want to investigate it further. Today, some Windows shenanigans occurred and broke my layout(Nothing new was installed or updated, windows updates are frozen, and bit-flip is not realistic since ECC RAM is used, the machine was untouched for the entire night, uptime was 12 hours), Instead of the default QWERTY layout, the layout is now tateisukan(たていすかん) and I would care less and just reboot it to fix that, but when I opened mpv, it detected input in half-width katakana. That was weird, so I tested everything that I could: windows search, explorer, process hacker, firefox, chromium, keepassxc, qbittorrent, libreoffice, notepad. Everything worked fine and captured keys as romaji, except mpv(However, I was able to pass the actual input to mpv via the cmd, but not the GUI). I also killed and restarted every process that I could - RuntimeBroker, ApplicationFrameHost, ImeBroker, TextInputHost, StartMenuExperienceHost, dwm, explorer, but that didn't help. I won't reboot the machine yet in case someone wants to investigate this further. if I had to guess, there might be some library issues.

Expected Behavior

The input method should use half-width alphanumeric input.

Actual Behavior

The input uses half-width katakana.

Log File

output.txt

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[0x21D8]

If no one is interested in debugging, I'll close the issue because electricity isn't free and waiting isn't worth it.

[kasper93]

Maybe @na-na-hi have ideas? I don't really know much about IME stuff. We have some shenanigans with switching the mode in gui thread, not sure if that might be related.

[na-na-hi]

Have you tried to press the eisu/英数 key? I guess Windows have a alphanumeric/tateisukan state kept for programs that are not IME aware (--input-ime=no) and mpv is using the wrong keymap.

[0x21D8]

@na-na-hi
Okay, so I've tested it, and apparently windows doesn't detect mpv GUI as an available input source, I can't switch inputs with alt+`, alt + caps and shift + caps. Every other application works fine. You're probably right that mpv using the wrong keymap.

[0x21D8]

Interestingly enough, when using --input-ime=yes the IME actually detects it as a valid input source allowing input methods to be switched, without this glitch it should obviously detect the input without --input-ime=yes flag, but it does not.

@kasper93
This might actually be related to what you described. I wonder if it is a duplicate or if it is some other deeper issue.

[0x21D8]

I backtracked a little and tracked down mpv-x86_64-20160229 and mpv-0.30.0-x86_64 and tested both, they're still spitting the same error: [input] No key binding found for key 'ﾀ'.. The IME doesn't detect the GUI as an available input source, the issue night be pretty old, or something weird is really happening.