Typing on a remote phone: Turkish characters, keyboards and why text goes wrong
You type ş and something else appears, or nothing does. Two machines are disagreeing about what your keyboard is, and which way the disagreement goes depends on how the tool sends text.
Two ways to send a keystroke
As a key position. The tool sends "the key at position 44 was pressed" and the remote device applies its own layout to decide what character that is. This preserves shortcuts and modifier keys perfectly, and it breaks the moment the two layouts differ.
As text. The tool sends the character itself — ş — and the remote device inserts it directly. This always produces the right character regardless of layout, and it does not work for shortcuts, because there is no key being pressed for the app to react to.
| Method | Turkish characters | Shortcuts and modifiers | Games and key-state apps |
|---|---|---|---|
| Key positions | Only if layouts match | Perfect | Works |
| Text insertion | Always correct | Does not work | Does not work |
| Both, chosen per input | Correct | Works | Mostly works |
Why Turkish is where this shows up
- Two national layouts. Turkish Q and Turkish F place letters completely differently, and F is not a variant of Q — it is a different design. A remote phone set to one while you type on the other produces nonsense.
- Letters outside ASCII.
ç ğ ı İ ö ş üsit in different places on each layout, and a device configured for English has no key position that produces them at all. On that device, no key you press can make them. - Dotted and dotless i. Turkish distinguishes
i/İfromı/Iand applies different case rules. Software assuming English casing turns one into the other, which is bewildering inside a remote session where you already suspect the keyboard.
What to do
- Match the keyboard on the remote phone to what you are typing on, if the tool sends key positions. Android: Settings → System → Languages & input → On-screen keyboard → your keyboard → Languages. One-time change, and it survives restarts.
- Use the tool's text-send feature for anything long. A password, an address, a paragraph. It sidesteps layout entirely.
- Watch the first two characters. If they are wrong in a consistent way — the same substitutions every time — it is a layout mismatch. If they are random or missing, it is a connection problem, not a keyboard one.
- Use the remote phone's own keyboard for one awkward character. Tapping it on the remote screen produces exactly what that device would produce, always.
- Check the autocorrect on the remote phone. Its keyboard may be "correcting" your input into another language's words — this looks like a transmission fault and is not one.
The thing that is not a keyboard problem
If every character arrives correctly but late — you type ahead of what appears — that is latency, not layout. Different problem, different guide: why the remote tap lands late.
And if nothing you type appears at all while the screen is clearly live, the control permission is missing on the remote phone. The video arriving proves the connection is fine; input needs a separate and much stronger permission — see the accessibility permission.
More guides
The code does not work: why the two phones will not pair
Stale codes, the wrong phone reading the code, background limits killing the app, and networks that block direct connections. A diagnosis order that finds the cause in minutes.
Setting up a first session: who shares, who connects, and what each side needs
The two roles are not symmetric and that is where first attempts go wrong. What to install where, which permission belongs to which side, and a five-minute test before you rely on it.
Picture but no control, freezing, or a black screen: a diagnosis order
Six symptoms that look alike and have completely different causes. What each one tells you, in the order that finds the answer fastest.
Try Remote Phone
Share an Android screen, or control one from another phone or your computer's browser. No account needed.
Try Remote Phone