Bug 80141

Summary:	Anaconda doesn't support new xkb model
Product:	[Retired] Red Hat Linux	Reporter:	Leonid Kanter <leon>
Component:	XFree86	Assignee:	Mike A. Harris <mharris>
Status:	CLOSED DUPLICATE	QA Contact:	David Lawrence <dkl>
Severity:	high	Docs Contact:
Priority:	medium
Version:	9	CC:	aleksey, ekanter, katzj, mharris, milan.kerslager
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-02-21 18:50:29 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	79578

Description Leonid Kanter 2002-12-20 16:40:24 UTC

If beta2 is configured in installer for using "ru" keyboard or other non-latin1
keyboard from list below by default, it's impossible to switch from national
input to us-ascii and, as a result, impossible to add new user in firstboot
application and login as root in gdm (see bug 79287). I contacted one of the
core XKB developers, Ivan Pascal <ivan>, and he told me that xkb behavior
significantly changed since 4.2. In 4.2 it was enough to load only "ru" layout
because "ru" had also en_US keyboard inside, and it was possible to set up
switch (option grp:ctrl_shift_toggle for example) to enter both cyrillic and
us-ascii characters. Currently all national layouts are assumed to be
monolithic, and they must be loaded together with "us" layout. Additionally,
layout switch must be configured to allow switching between us layout and
national layout. So, xkb section may look as:

Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "keyboard"
    Option      "XkbLayout"    "us,ru"
    Option      "XkbOptions"    "grp:ctrl_shift_toggle"
EndSection


To restore old bahavior of xkb, following patch must be applied:

--- XFree86-4.2.99.2/xc/programs/xkbcomp/rules/xfree86.orig
2002-11-26 03:43:25.000000000 +0200
+++ XFree86-4.2.99.2/xc/programs/xkbcomp/rules/xfree86  2002-12-20
17:44:54.000000000 +0200
@@ -13,8 +13,8 @@

 // If you want non-latin layouts implicitly include the en_US layout
 // uncomment lines below
-//! $nonlatin = am ar ben bg by dev el ge_la ge_ru guj gur il il_phonetic\
-//              ir iu mk mm ru sr th tj tml ua
+! $nonlatin = am ar ben bg by dev el ge_la ge_ru guj gur il il_phonetic\
+              ir iu mk mm ru sr th tj tml ua

 ! $pcmodels = pc101 pc102 pc104 pc105
 ! $mac = macintosh macintosh_old

This list is actually a list of layouts that use non-latin1 characters
and with new model they must always be loaded together with "us" layout. So,
anaconda must know this list and configure keyboards from this list together
with us keyboard ("us,ru") and configure switch between us and non-us layout
(see keyboard configuration in WinXP installer, for example).

Comment 1 Aleksey Nogin 2002-12-20 22:36:41 UTC

> This list is actually a list of layouts that use non-latin1 characters
> and with new model must always be loaded together with "us" layout. 

Ideally, it should also be capable of updating existing XF86Config on upgrade.

Comment 2 Milan Kerslager 2003-01-21 14:10:06 UTC

Changing version to Beta4

Comment 3 Aleksey Nogin 2003-01-22 03:02:24 UTC

IMHO this deserves severity: high since it is capable of making X unusable
(until one figures out how to fix the config).

Comment 4 Brent Fox 2003-01-22 05:17:06 UTC

I think that this should actually be an XFree86 bug.  I have no way of
guaranteeing that the user will install/upgrade redhat-config-keyboard, so
there's no guarantee that the migration will take place.  I think that XFree86
should make this change when it is upgraded.

Now, redhat-config-keyboard *does* need to be changed to be able to write out
XF86Config that contains both keymaps for the languages that need them (bug
#82440), but the actual migration of the XF86Config file on upgrades needs to be
done by XFree86 itself.

Comment 5 Mike A. Harris 2003-01-22 23:30:20 UTC

I'd like to see how that is possible, without requiring weeks of development
and 400kb RPM post install scripts.

Not likely going to be done by XFree86.  I consider this entirely
a config tool issue.

Comment 6 Milan Kerslager 2003-01-23 06:31:48 UTC

Maybe not full logic, but simple inserting comment to XF86Config near keyboard
section.

Comment 7 Leonid Kanter 2003-01-23 11:03:52 UTC

If you apply patch listed above, everything should work exactly like in 4.2, but
it would be ignoring of new xkb features.

There is one more way: disable X keyboard configuration in inslaller and let to
the user configure keyboard himself using user-space graphical gnome
configuration  tool - gswitchit, which is not included to distribution yet. kxkb
from kde also works somehow.

Comment 8 Aleksey Nogin 2003-01-23 20:25:54 UTC

Is it safe to mark this as a dup of bug 79287 now? Or as MODIFIED by bug 82440?

Comment 9 Leonid Kanter 2003-01-23 20:51:11 UTC

I think yes. Looks like the problem will be solved in bug 82440, if anaconda use
the same code.


*** This bug has been marked as a duplicate of 79287 ***

Comment 10 Brent Fox 2003-01-24 00:30:42 UTC

mharris: We have no guarantee that the user will run the config tool on an
upgrade.  Firstboot doesn't run on an upgrade and anaconda will not modify the
XF86Config file on an upgrade.  There's no guarantee that the user has
redhat-config-keyboard installed, so the problem can't be solved by the config
tool.  I have modified redhat-config-keyboard to do the right thing once it has
been run, but there's no way to make it run on an upgrade.

The way I see it, the only guarantee that we have is that the %post section of
XFree86 will be run if XFree86 is upgraded.  For example, imagine that I have an
8.0 system that uses the 'ru' keymap and I upgrade XFree86 by hand, including
all the packages that will require.  When I restart X, BAM!, I can't toggle to a
us keymap anymore.  XFree86 should be able to change that one line in the config
file without requiring that the user run some other config tool.  I know it's
difficult, but don't you think that's the right thing to do?

Comment 11 Aleksey Nogin 2003-01-24 01:19:32 UTC

IMHO the only real alternative to messing with configs on upgrade (which might
have undesired implications) is to mention the issue in the release notes (see 
bug 82440 comment #5) and/or pop up a warning in anaconda, possibly also asking
whether user wants anaconda to regenerate the config.

Comment 12 Mike A. Harris 2003-01-24 06:03:04 UTC


*** This bug has been marked as a duplicate of 79287 ***

Comment 13 Red Hat Bugzilla 2006-02-21 18:50:29 UTC

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.