Red Hat Bugzilla – Bug 143014
Cannot input composed characters on Linux console (Unicode mode)
Last modified: 2015-01-04 17:14:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; el-GR; rv:1.7.5)
Description of problem:
Unicode mode in Linux console does not currently allow the input of
In other words, while in console in Unicode mode, you cannot write
accented characters using dead keys, due to a deficiency of the kernel
in this area.
There has been a discussion on LKML on this issue.
Start from http://www.ussg.iu.edu/hypermail/linux/kernel/0412.1/0796.html
and read the followups for the background.
Then, check http://www.ussg.iu.edu/hypermail/linux/kernel/0412.1/1039.html
for an initial patch(simple hack) that solves the problem.
Check followups as well.
An alternative patch can be found at
At least the following languages (+composed characters) are affected:
gr: Greek ά έ ί ό ύ ώ ϊ ϋ
ϊ Ά Έ Ί Ή Ύ Ϋ
es: Spanish ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½
nl: Dutch ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½
cz: Czech ï¿½ ï¿½ ï¿½
us-ascentos: ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½
cf: french-canadian ï¿½ ï¿½ ï¿½ ï¿½ ï¿½
fi: Finish ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½
fr French ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½
Solving this issue, Fedora can claim input/output UTF-8 support for
Version-Release number of selected component (if applicable):
Steps to Reproduce:
We make a minimal demonstration file instead of using the existing
keymap files, found in /lib/kbd/keymaps/*.
1. Create minimal keymap for spanish.
% cat minimal-keymap-spanish.map
keycode 53 = 0x0d2f
keycode 2 = U+00E1
keycode 3 = U+00E9
compose '/' 'a' to U+00E1
compose '/' 'e' to U+00E9
"2f" is character "/".
"0d" means we use "/" as dead key here.
U+00E1 is ï¿½
U+00E9 is ï¿½
keycode 2 is key "1"
keycode 3 is key "2"
2. Log on on console (no xterm :)). Use "bash" shell.
3. Run "unicode_start latarcyrheb-sun16" to reset to Unicode input.
(Just make sure all are ok, as this has been done already).
4. Run "loadkeys minimal-keymap-spanish.map"
5. Hit "1" key to generate "ï¿½", to verify it's working.
6. Hit "/" + "a" to try to generate "ï¿½". It does not work due to a
Actual Results: The byte "e1" is emmited (comes from U+00E1).
This is not valid UTF-8, so nothing is displayed.
You can view the byte by typing:
% echo -n "<type it here>" | hexdump -C
Expected Results: "ï¿½" should be displayed at step 6. (In UTF-8, it's
Added bugzilla report to bugzilla.kernel.org.
X-linked that report to this.
It looks Bugzilla does not support UTF-8 :-/
to view a similar page of the bug report in UTF-8. You may need to
change the browser encoding to UTF-8.
Discussion LKML in 2002 about revamping the unicode console support in
the Linux kernel.
and then click on "Thread Index" to see the full thread.
Article on Linux Gazette by En D Loozzr, titled: "How Linux Console
Fonts Work ", at http://linuxgazette.net/issue91/loozzr.html
Covers 2.4/2.6, it's good reading.
Hold your horses.
There has been a discussion on the linux-utf8 mailing about Unicode on
the Linux console that significantly changes what is requested in the
You can untangle the new information by starting at
Currently, the Linux kernel provides a so-called "emergency console"
which is the console interface we are used to when running on runlevel 3.
There has been a need to read/write Unicode and the easy solution was
to add to this emergency console limited support for Unicode. Adding
to the emergency console means that we add to the Linux kernel,
something that the kernel developers are not happy about.
The proper way to have Unicode support in the Linux Console is to use
the framebuffer (so we can represent the full Unicode 4.x standard)
and write a suitable terminal emulator. For input support, IIIMF looks
Now, such a terminal emulator exists, but needs development assistance
to become more mature. It's UTERM, found at
As soon as work starts on a terminal emulator (based on UTERM or
something else), I'll close this bug report and add a link to the new
*** Bug 75811 has been marked as a duplicate of this bug. ***
*** Bug 75430 has been marked as a duplicate of this bug. ***
*** Bug 116667 has been marked as a duplicate of this bug. ***
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
The problem is not fixed by the errata.
Is there a link to the patch/change that tries to fix this bug?
(NEEDINFO means "developer needs info from reporter", not the other way around)
Mass update to all FC4 bugs:
An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (188.8.131.52). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.
Please retest with this update, and update this bug if necessary.
The bug has not been fixed with linux kernel 2.6.13-1.1526_FC4.
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
Nope, no fix yet. This is probably a good candidate for a WONTFIX or at least
UPSTREAM, since it's very unlikely that the kernel will ever be able to detect
what locale the console is on to decide how to produce non-ASCII characters.
I would concur on this.
From the discussion on the kernel mailing list, this is an issue to better solve
indeed. It's a feature request, and those sorts of things really need to go
through upstream first rather than live in a vendor tree.