Bug 80141 - Anaconda doesn't support new xkb model
Anaconda doesn't support new xkb model
Status: CLOSED DUPLICATE of bug 79287
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
All Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks: 79578
  Show dependency treegraph
 
Reported: 2002-12-20 11:40 EST by Leonid Kanter
Modified: 2008-01-17 12:49 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:50:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Leonid Kanter 2002-12-20 11:40:24 EST
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@tsu.ru>, 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 17:36:41 EST
> 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 09:10:06 EST
Changing version to Beta4
Comment 3 Aleksey Nogin 2003-01-21 22:02:24 EST
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 00:17:06 EST
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 18:30:20 EST
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 01:31:48 EST
Maybe not full logic, but simple inserting comment to XF86Config near keyboard
section.
Comment 7 Leonid Kanter 2003-01-23 06:03:52 EST
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 15:25:54 EST
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 15:51:11 EST
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-23 19:30:42 EST
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-23 20:19:32 EST
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 01:03:04 EST

*** This bug has been marked as a duplicate of 79287 ***
Comment 13 Red Hat Bugzilla 2006-02-21 13:50:29 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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