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).
> 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.
Changing version to Beta4
IMHO this deserves severity: high since it is capable of making X unusable (until one figures out how to fix the config).
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.
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.
Maybe not full logic, but simple inserting comment to XF86Config near keyboard section.
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.
Is it safe to mark this as a dup of bug 79287 now? Or as MODIFIED by bug 82440?
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 ***
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?
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.
*** This bug has been marked as a duplicate of 79287 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.