Weird behavior with Windows IME
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 37k
- Forks
- 3.5k
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 22
Description
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
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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the attached output.txt and comparing mpv's GUI input behavior with and without --input-ime=yes under the reported Windows IME state. Done would require a reproducible case and confirmation that GUI input uses half-width alphanumeric input rather than half-width katakana.
Written by the indexing model from the issue text.
Assessment
- Domain
- desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100