RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1181581 - composing keys don't work as expected
Summary: composing keys don't work as expected
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kbd
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Vitezslav Crhonek
QA Contact: Robin Hack
URL:
Whiteboard:
Depends On:
Blocks: 1393870 1400961
TreeView+ depends on / blocked
 
Reported: 2015-01-13 12:08 UTC by Karel Volný
Modified: 2017-08-01 16:51 UTC (History)
9 users (show)

Fixed In Version: kbd-1.15.5-13.el7
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2017-08-01 16:51:51 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
proposed patch (17.19 KB, patch)
2015-08-10 09:41 UTC, Vitezslav Crhonek 		no flags Details | Diff
proposed keymap patch (15.27 KB, patch)
2015-08-10 09:44 UTC, Vitezslav Crhonek 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1178588 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Bugzilla 1182562 0 unspecified CLOSED Text interface broken for non-latin languages 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2017:1978 0 normal SHIPPED_LIVE kbd bug fix update 2017-08-01 17:58:01 UTC

Internal Links: 1178588 1182562

Description Karel Volný 2015-01-13 12:08:51 UTC 
Description of problem:
While testing bug 1002450 I came across a problem composing national characters via deadkeys.

Version-Release number of selected component (if applicable):
RHEL-7.1-20150107.n.0

How reproducible:
always

Steps to Reproduce:
1. start text mode installation appending "text keymap=cz" onto kernel commandline
2. try to write sample text
3. switch to console via alt+f2
4. write the same text
5. hold backspace to delete all the text you've written

Actual results:
2 and 4. příliš žlu^toučký ků^n úpěl ^dábelské kódy
(see the attachment 979566 [details] to bug 1002450)

5. [anacond root@lo
(part of the shell prompt gets deleted)

Expected results:
2 and 4. příliš žluťoučký kůň úpěl ďábelské kódy

5. [anaconda root@calhost /]# 
(the shell prompt cannot be deleted)

Additional info:
Czech keyboard makes use of four combining symbols:
1. ring accent (˚) at tilde (~) position
2. acute accent (´ - not apostrophe) at equals sign (=) position
3. caron (ˇ) at plus (+) position
4. diaresis (¨) at backslash (\) position

actual behaviour is that
1. doesn't work at all, it just prints the degree sign
2. works only for some characters - áéíóúý - otherwise it prints apostrophe and the corresponding letter; however, the Unicode standard allows also ć (U+0107), ĺ (U+013A) etc. etc.
3. replaced by circumflex, also works just for a subset of applicable characters
4. also works just for a subset of applicable characters, otherwise prints quotation marks and the letter

Note that I do not know where does the problem originate, I file for systemd as to my best knowledge, it is 'localectl' which is responsible for feeding correct parameters to loadkeys and also setting the console mappings so multibyte characters are handled properly - if that's incorrect, please reassign as appropriate.
Comment 2 Michal Sekletar 2015-01-14 14:53:10 UTC 
Can you please generate new anaconda image and retest? But please use newest dracut from brew.
Comment 6 Karel Volný 2015-01-16 14:09:20 UTC 
(In reply to Michal Sekletar from comment #2)
> Can you please generate new anaconda image and retest? But please use newest
> dracut from brew.

according to journal there is

dracut-7.1 (Maipo) dracut-033-238.el7

in the latest compose as of today, and I can still reproduce the problems ...
Comment 7 Michal Sekletar 2015-01-19 09:19:39 UTC 
Seems like this report is related to #1178588 and #1182562.
Comment 10 Michal Sekletar 2015-06-16 08:03:03 UTC 
I just retested this with latest RHEL7. I was installing VM and connected to it via serial console. I was able to type for example Č without issues. Please verify if appropriate. Thanks.
Comment 11 Karel Volný 2015-06-16 10:28:19 UTC 
(In reply to Michal Sekletar from comment #10)
> I just retested this with latest RHEL7. I was installing VM and connected to
> it via serial console. I was able to type for example Č without issues.
> Please verify if appropriate. Thanks.

still the same (... ^t ... ^n ... ^d ...) for me with RHEL-7.1-20150219.1-Server-x86_64-boot.iso

but that compose seems a bit aged :-(

what version do you call "latest" and where you got it (if it is newer than mine)?
Comment 12 Jan Synacek 2015-06-25 11:01:44 UTC 
Any idea when this actually worked correctly? It has "worked" like this at least from Fedora 20 (I can reproduce it on F20 and F22 as well).
Comment 13 Jan Synacek 2015-06-25 11:03:37 UTC 
To reproduce this, just boot the system, switch to a text tty (ctrl+alt+F3 for example), log in, call 'loadkeys cz' and type away.
Comment 14 Karel Volný 2015-06-25 13:03:42 UTC 
(In reply to Jan Synacek from comment #12)
> Any idea when this actually worked correctly?

/me can't remember seeing this working in installer ...

some fresh info after a talk with Michal:

- the difference in Michal's setup is the serial console; it looks like the composing happens *before* sending anything to the system being installed, i.e. it doesn't test this case

- my original assumption that systemd's localectl provides wrong parameters when loading the keymap turned out wrong, it can be reproduced also when the maps are loaded manually, as suggested in comment #13

so this really should be reassigned ... the question is, kbd or kernel?
Comment 15 Jan Synacek 2015-06-26 10:13:29 UTC 
I would start with kbd.
Comment 16 Karel Volný 2015-06-30 06:45:57 UTC 
FTR, the composing keys work on my Gentoo machine with sys-apps/kbd-1.15.5-r1 and kernel 3.18.12-gentoo
Comment 17 Karel Volný 2015-06-30 11:58:07 UTC 
(In reply to Karel Volný from comment #16)
> FTR, the composing keys work on my Gentoo machine with
> sys-apps/kbd-1.15.5-r1 and kernel 3.18.12-gentoo

not to rely on "my machine", it can be tested using the install iso[*] like:

$ qemu-kvm -m 1024 -cdrom install-amd64-minimal-20150625.iso

# loadkeys cz
Loading /usr/share/keymaps/i386/qwertz/cz.map.gz
# echo ť | hexdump
00000000 a5c5 000a
00000003


note that trying to write "ť" you'll get square as the install iso doesn't have appropriate fonts, hence using hexdump to verify that we got 0xC5 0xA5 as UTF-8 representation of "ť"


[*] http://distfiles.gentoo.org/releases/amd64/autobuilds/20150625/install-amd64-minimal-20150625.iso
Comment 18 Vitezslav Crhonek 2015-07-01 13:48:28 UTC 
(In reply to Karel Volný from comment #17)
> (In reply to Karel Volný from comment #16)
> > FTR, the composing keys work on my Gentoo machine with
> > sys-apps/kbd-1.15.5-r1 and kernel 3.18.12-gentoo
> 
> not to rely on "my machine", it can be tested using the install iso[*] like:
> 
> $ qemu-kvm -m 1024 -cdrom install-amd64-minimal-20150625.iso
> 
> # loadkeys cz
> Loading /usr/share/keymaps/i386/qwertz/cz.map.gz
> # echo ť | hexdump
> 00000000 a5c5 000a
> 00000003
> 
> 
> note that trying to write "ť" you'll get square as the install iso doesn't
> have appropriate fonts, hence using hexdump to verify that we got 0xC5 0xA5
> as UTF-8 representation of "ť"
> 
> 
> [*]
> http://distfiles.gentoo.org/releases/amd64/autobuilds/20150625/install-amd64-
> minimal-20150625.iso

"loadkeys cz" loads different keymap on RHEL/Fedora than on Gentoo. It loads "/lib/kbd/keymaps/xkb/cz.map.gz" (automatically generated from czech X server keyboard layout).

The keymap which you've loaded is placed here: "/lib/kbd/keymaps/legacy/i386/qwertz/cz.map.gz".
Comment 19 Karel Volný 2015-07-01 14:07:09 UTC 
(In reply to Vitezslav Crhonek from comment #18)
> "loadkeys cz" loads different keymap on RHEL/Fedora than on Gentoo.

thanks for taking a look

so ... can we conclude that the problem is with the keymap itself (or the way it is generated), or is it just first step in investigation?
Comment 20 Vitezslav Crhonek 2015-08-03 14:29:28 UTC 
(In reply to Karel Volný from comment #19)
> (In reply to Vitezslav Crhonek from comment #18)
> > "loadkeys cz" loads different keymap on RHEL/Fedora than on Gentoo.
> 
> thanks for taking a look
> 
> so ... can we conclude that the problem is with the keymap itself (or the
> way it is generated), or is it just first step in investigation?

Yes, it seems that there's problem with the generated keymap - it's missing compose rules, because adding this line:

compose '^' 't' to U+0165

at the end of keymap file (/lib/kbd/keymaps/xkb/cz.map.gz) fixes the issue with "ť" for me.
Comment 21 Vitezslav Crhonek 2015-08-10 09:41:07 UTC 
Created attachment 1060992 [details]
proposed patch
Comment 22 Vitezslav Crhonek 2015-08-10 09:44:15 UTC 
Created attachment 1060993 [details]
proposed keymap patch
Comment 28 errata-xmlrpc 2017-08-01 16:51:51 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1978
Note You need to log in before you can comment on or make changes to this bug.