Bug 5272 - Impossible to use non-Roman keyboard layout on macOS
Summary: Impossible to use non-Roman keyboard layout on macOS
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: 4.2.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Pierre Ossman
Depends on:
Blocks: keyboard
  Show dependency treegraph
Reported: 2014-09-25 13:00 CEST by Peter Åstrand
Modified: 2021-12-14 09:09 CET (History)
1 user (show)

See Also:
Acceptance Criteria:

patch for FLTK (3.29 KB, patch)
2019-04-04 11:37 CEST, Pierre Ossman

Description Peter Åstrand cendio 2014-09-25 13:00:00 CEST
On Mac OS X, the Russian keyboard layout is apparently implemented as, or requires, input methods. Since our current approach is to let input method handling be done on the server side, we are disabling input methods in vncviewer. When this happens, the keyboard layout changes to someelse else(!) 

The same effect can also be seen in Firefox or Safari, when switching to a password input field. This is somewhat surprising. 

I've verified this on both 10.4 and 10.9, so this is not something new. Note however that 10.4 has a more advanced control panel UI, which describes layout type. The Swedish layout is described as "Keyboard/Roman", while the Russian layout is "Keyboard/Cyrillic". Katakana is a subtype of "Kotoeri", of type "Input method/Japanese". 

My conclusion is that the problem is not that the Russian layout requires "Input methods", but rather that it is of a non-Roman type.
Comment 1 Peter Åstrand cendio 2014-09-25 13:06:33 CEST
Apparently, non-latin passwords are not allowed on Mac OS X. Other person with same problem:

Comment 2 Peter Åstrand cendio 2014-09-29 11:06:39 CEST
It turns out that this is a problem for other layouts as well, for example Greek. The Greek alphabet is a parent for the Latin/Roman alphabet, so it is perhaps not a surprise that a Greek layout is not accepted on OS X, since we are apparently restricting ourselves to Roman layouts.
Comment 4 Pierre Ossman cendio 2019-04-04 10:59:48 CEST
Apple has apparently decided to hide the internal details of keyboard handling. Fortunately the internet never forgets:

Comment 5 Pierre Ossman cendio 2019-04-04 11:37:10 CEST
Created attachment 906 [details]
patch for FLTK

I was looking at the macOS keyboard input for an upstream issue, and I think I stumbled upon a way to solve this.

The attached patch seems to disable the stuff we don't want, and keep the things we do.

Instead of filtering out only "ASCII" input sources, we instead we focus on those that claim to be of the basic "Layout" type. This should exclude various forms of input methods.

Needs more testing, but it seems promising.

(this method also seems to match the system settings, which refuses to let you remove the last "normal" input source)
Comment 6 Pierre Ossman cendio 2021-12-14 09:08:42 CET
(In reply to Pierre Ossman from comment #5)
> (this method also seems to match the system settings, which refuses to let
> you remove the last "normal" input source)

This seems to have changed. I couldn't configure macOS 12 to only have Russian layout.

Note You need to log in before you can comment on or make changes to this bug.