Hi, I just packed console-setup (Tools for configuring the console using X Window System keymaps) for Fedora. I think that it would be useful to integrate it with systemd to make X Window System keymaps available to users in the Anaconda. For more information, see: https://bugzilla.redhat.com/show_bug.cgi?id=680990 https://bugzilla.redhat.com/show_bug.cgi?id=833855
Can you give is a quick rundown how the new scheme works? Does c-s convert all xkb files dynamically to the console format or do they come precompiled? Which tools do we have to call now? Is there value in supporting the old kbd mappings? If so, are they preferable if they exist over the respective one from c-s? Should the old stuff just go away entirely?
(In reply to comment #1) > Can you give is a quick rundown how the new scheme works? Sure. c-s ships two scripts - /usr/bin/ckbcomp (perl script, which converts xkb files to the console format) and /usr/bin/setupcon (shell script, which reads configuration files and then sets keymaps and/or console font using "classic" tools from kbd - loadkeys, setfont, etc.). There are two configuration files - /etc/default/console-setup (identifies which xkb keymap and variant will be used, it's also possible to use any keymap shipped within kbd) and /etc/default/keyboard (used to select console font - however, at this time it can only use fonts shipped within s-c, as they have special naming). The rest of s-c package are fonts/trans and documentation. > > Does c-s convert all xkb files dynamically to the console format or do they > come precompiled? Dynamically, setupcon calls ckbcomp, which converts the xkb file into console keymap, writes it into temporary file in /tmp, loadkeys loads it and the temporary file is finally removed. > > Which tools do we have to call now? /usr/bin/setupcon Maybe we can use it just for loading keymap - with "-k" flag, then only /etc/default/console-setup should be configured and no change to console fonts setting is necessary. > > Is there value in supporting the old kbd mappings? If so, are they > preferable if they exist over the respective one from c-s? I'm not sure. But it's easy to support it (set KMAP variable in /etc/default/console-setup with path to the keymap from kbd). > > Should the old stuff just go away entirely? The old stuff - if you mean kbd - will stay untouched. c-s is on top of the kbd.
This is somewhat problematic - bringing perl into every system just to install the keymap isn't really practical. setupcon looks like it might be overkill with systemd's vonconsole-setup, if all it does is read configuration and call the kbd/etc tools.
Right, we can not use that in systemd by default. We do not want to compile stuff on demand to upload that to the kernel. It can surely be done as an optional add-on people can install, but not we will not require that as the default. Especially not involving 4000 lines perl scripts running at bootup. :) That tool either needs to be converted to C and read the map file and put it _directly_ into the kernel, also without needing loadkeys. That would be the optimal solution for that specific problem. Or we need to pre-compile maps and ship them if that makes things easier than the current solution. Or we leave things just as they are, and wait for frame buffer based virtual consoles (using wayland/kms) which people are working on already. These can do _real_ fonts and _real_ keymaps and do not need that ancient limited and incapable kernel hackery which can only draw 256/512 different glyphs.
Vitezslav, is there any chance of comming up with a better acceptable solution for the systemd? If not, what packages and calls are needed in Anaconda to use the new functionality?
(In reply to comment #5) > is there any chance of comming up with a better acceptable solution for the > systemd? I absolutely agree that it is suboptimal to have two different sets of key mappings for X11 and the console. So I think we could benefit from this package, but this should not involve perl in the boot process. My recommendation would hence be to convert the X11 keymaps as part of the build process and include them fully converted in the kbd package. Hence: use the perl script to convert the maps offline, not online, and things would be much nicer for us. > If not, what packages and calls are needed in Anaconda to use the > new functionality? anaconda should just call SetX11Keyboard() and set convert=True, in order to not only set the X11 kbd map, but also find the matching console one and set that: http://www.freedesktop.org/wiki/Software/systemd/localed
(In reply to comment #6) > anaconda should just call SetX11Keyboard() and set convert=True, in order to > not only set the X11 kbd map, but also find the matching console one and set > that: > > http://www.freedesktop.org/wiki/Software/systemd/localed AFAIK SetX11Keyboard() doesn't allow us to setup multiple X layouts and is therefore not usable for Anaconda. We could, however, use it for finding matching console layout, but a) would it also load the correct font? b) we have a request to provide all X layouts for console So I guess we would have to use console-setup tools for now and hope it get's resolved in a better way in the future.
(In reply to comment #7) > (In reply to comment #6) > > anaconda should just call SetX11Keyboard() and set convert=True, in order to > > not only set the X11 kbd map, but also find the matching console one and set > > that: > > > > http://www.freedesktop.org/wiki/Software/systemd/localed > AFAIK SetX11Keyboard() doesn't allow us to setup multiple X layouts and is > therefore not usable for Anaconda. We could, however, use it for finding > matching console layout, but Multiple X layouts? What is this about? Why does Anaconda need that even though GNOME later on does not expose this? > a) would it also load the correct font? What would that be? Usually some UTF8 font should be enough. Why would we make the font dependent on the keymap? > b) we have a request to provide all X layouts for console Well, I don't see why anaconda should offer a different console key map set here then the usual console does after installation. As mentioned, if you want the full maps, then please convert them offline, not during runtime. > So I guess we would have to use console-setup tools for now and hope it > get's resolved in a better way in the future. I don't follow.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > anaconda should just call SetX11Keyboard() and set convert=True, in order to > > > not only set the X11 kbd map, but also find the matching console one and set > > > that: > > > > > > http://www.freedesktop.org/wiki/Software/systemd/localed > > AFAIK SetX11Keyboard() doesn't allow us to setup multiple X layouts and is > > therefore not usable for Anaconda. We could, however, use it for finding > > matching console layout, but > > Multiple X layouts? What is this about? Why does Anaconda need that even > though GNOME later on does not expose this? Because people want to type their names with all characters they really contain and at the same time they want to easily type some other characters as their password (e.g. typing '$' with the czech layout is almost impossible). > > > a) would it also load the correct font? > > What would that be? Usually some UTF8 font should be enough. Why would we > make the font dependent on the keymap? If the default is really a UTF8 font, then it should be okay. Testing on my laptop running Fedora 17 doesn't look like that. > > > b) we have a request to provide all X layouts for console > > Well, I don't see why anaconda should offer a different console key map set > here then the usual console does after installation. Well, I don't see any big advantage in this too, but it was requested and honestly, it's not anaconda's business that the other tools don't support the full list of layouts (including X layouts) even if they can (by using console-setup).
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #6) > > > > anaconda should just call SetX11Keyboard() and set convert=True, in order to > > > > not only set the X11 kbd map, but also find the matching console one and set > > > > that: > > > > > > > > http://www.freedesktop.org/wiki/Software/systemd/localed > > > AFAIK SetX11Keyboard() doesn't allow us to setup multiple X layouts and is > > > therefore not usable for Anaconda. We could, however, use it for finding > > > matching console layout, but > > > > Multiple X layouts? What is this about? Why does Anaconda need that even > > though GNOME later on does not expose this? > > Because people want to type their names with all characters they really > contain and at the same time they want to easily type some other characters > as their password (e.g. typing '$' with the czech layout is almost > impossible). Well, but why would they only want to do that in Anaconda, and not in the normal console? If we should do something about multiple keymaps, then we should solve that for good, not just for Anaconda. > > > a) would it also load the correct font? > > > > What would that be? Usually some UTF8 font should be enough. Why would we > > make the font dependent on the keymap? > If the default is really a UTF8 font, then it should be okay. Testing on my > laptop running Fedora 17 doesn't look like that. Well, then please file a bug. We load latarcyrheb-sun16 by default which should be a good choice for UTF-8 and contains most western glyphs just fine. > > > b) we have a request to provide all X layouts for console > > > > Well, I don't see why anaconda should offer a different console key map set > > here then the usual console does after installation. > > Well, I don't see any big advantage in this too, but it was requested and > honestly, it's not anaconda's business that the other tools don't support > the full list of layouts (including X layouts) even if they can (by using > console-setup). I totally agree that this would be useful, but this should be fixed for everything, not just Anaconda. What works in Anaconda should also work in the normal system. I don't think that console-setup as is is a good choice for solving this specific issue though. If you want to make this work, then please try to rework it to convert the maps offline so that we can install the pre-compiled keymaps directly in an RPM, and I'd be more than happy to add the necessary hookups to localed for this.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > (In reply to comment #7) > > > > (In reply to comment #6) > > > > > anaconda should just call SetX11Keyboard() and set convert=True, in order to > > > > > not only set the X11 kbd map, but also find the matching console one and set > > > > > that: > > > > > > > > > > http://www.freedesktop.org/wiki/Software/systemd/localed > > > > AFAIK SetX11Keyboard() doesn't allow us to setup multiple X layouts and is > > > > therefore not usable for Anaconda. We could, however, use it for finding > > > > matching console layout, but > > > > > > Multiple X layouts? What is this about? Why does Anaconda need that even > > > though GNOME later on does not expose this? > > > > Because people want to type their names with all characters they really > > contain and at the same time they want to easily type some other characters > > as their password (e.g. typing '$' with the czech layout is almost > > impossible). > > Well, but why would they only want to do that in Anaconda, and not in the > normal console? I meant multiple X layouts not VConsole keymaps. > > If we should do something about multiple keymaps, then we should solve that > for good, not just for Anaconda. > > > > > a) would it also load the correct font? > > > > > > What would that be? Usually some UTF8 font should be enough. Why would we > > > make the font dependent on the keymap? > > If the default is really a UTF8 font, then it should be okay. Testing on my > > laptop running Fedora 17 doesn't look like that. > > Well, then please file a bug. We load latarcyrheb-sun16 by default which > should be a good choice for UTF-8 and contains most western glyphs just fine. > > > > > b) we have a request to provide all X layouts for console > > > > > > Well, I don't see why anaconda should offer a different console key map set > > > here then the usual console does after installation. > > > > Well, I don't see any big advantage in this too, but it was requested and > > honestly, it's not anaconda's business that the other tools don't support > > the full list of layouts (including X layouts) even if they can (by using > > console-setup). > > I totally agree that this would be useful, but this should be fixed for > everything, not just Anaconda. What works in Anaconda should also work in > the normal system. > > I don't think that console-setup as is is a good choice for solving this > specific issue though. If you want to make this work, then please try to > rework it to convert the maps offline so that we can install the > pre-compiled keymaps directly in an RPM, and I'd be more than happy to add > the necessary hookups to localed for this. In reaction to this statement we are patching Anaconda to handle X layouts and VConsole keymaps separately using systemd-localed for conversion between these two sets. Please let us know when some solution for loading X layouts in VConsole is available.
wish I'd caught the implications of this earlier, but we have a substantial mismatch between the X keymaps anaconda offers the user, and systemd's ability to convert them to console keymaps: https://bugzilla.redhat.com/show_bug.cgi?id=889562 input welcome.
Vitezslav, can you make perl merely a build time dep and generate the layouts at build time? That's better than status quo and gets us most of the way there.
(if having a BuildRequires: xkeyboard-config is problematic, you could just stuff the xkeyboard-config source tarball into the package too, I guess)
(In reply to comment #13) > Vitezslav, can you make perl merely a build time dep and generate the > layouts at build time? That's better than status quo and gets us most of > the way there. console-setup is not just for converting X layouts to console keymaps, but also for setting fonts, keyboard model, xkboptions etc. - removing perl from requires will make this package almost useless. But we can pack X layouts to separate/different package and convert them at build time as suggested. All we need to do is call 'ckbcomp "$XKBLAYOUT" "$XKBVARIANT" >$KEYMAPFILE' for every layout and variant from xkeyboard-config. I'm not sure about path and naming, but that's probably only matter of agreement. Does it make sense and will that help?
yea makes sense to me. You could probably just put them in kbd-misc
thoughts: what about layouts named the same in kbd and xkb? Would we want to just kill kbd, and use the converted-xkb layouts in all cases? Anyone know what Debian/Ubuntu do there?
that's what this bug is about primarily
well, as I read it, the bug seems to be about making xkb layouts available as console layouts. I don't see anywhere that explicitly suggests removing the existing console layouts.
Hello guys, I created SRPM for testing purposes, see: http://vcrhonek.fedorapeople.org/kbd/kbd-1.15.5-2.fc19.src.rpm If you build it, the kbd-misc-1.15.5-2.fc19.noarch subpackage will contain converted xkb layouts in the /lib/kbd/keymaps/x-converted/ directory (this can be changed of course). The list of layouts and variants is taken from /usr/share/X11/xkb/rules/base.xml (processed by slightly modified perl script taken from xkeyboard-config package sources). Please let me know what do you think.
(In reply to comment #19) > well, as I read it, the bug seems to be about making xkb layouts available > as console layouts. I don't see anywhere that explicitly suggests removing > the existing console layouts. I don't think we have to remove them - they could be still useful for some users. Be we should use converted X layouts by default to have same layout in console and X.
We definitely should keep the old maps around in order not to break upgrades. Might be worth to move them to some package "kbd-legacy" or so, but find a way so that is installed on uprades?
hey awesome work! thanks. seems to work okay in my brief testing. I was able to do loadkeys us-alt-intl and then type í
maybe instead of x-converted, call it xkeyboard-config
I'd just call them "xkb". It's where the data belongs. The fact that it is "configuration" is redundant and irrelevant and so is the fact that it got "converted".
Seems logical to me. Awesome work, Vita. Lennart, what's the next step here for integration? Can we make systemd simply use the X config file for the console and avoid the whole conversion step? That'd seem simplest.
To show my respect here: thanks a lot for just doing all that work, really, it looks great to me, and your work is appreciated. I looked at the package and it certainly was quite some work. This brings us a little bit closer to the imagined future. In the long run the xkb stuff will replace all the old console stuff, we might even step back from using the kernel VT stuff entirely some day and have a GL system compositor that can draw _real_ fonts and use _real_ input methods and the xkb keymaps. Today the kernel is limited to show 512 glyphs at the same time, which is really more a bad joke today for anything but latin languages. With that step we would also unify the fonts between X and the console. We really hope we can do better here in the future, but still on the surface behave like we do today. If we get there some day (might be years), the "dumb" kernel VT will then only be a "debug console" and not be used by any ordinary console user, unless the box is really broken, and needs debugging. So, thanks again for making all that happen, even if it might not be what you had in mind in the first step, it certainly is what we thing makes the most sense today looking towards the future. We will probably get rid of the translation table next, and update the mechanism in systemd to change the locale/keymap to reflect that simpler scheme. We haven't really sorted out all the details, we'll come back when we get there updating the systemd part.
Hmm, regarding the translation table, here's an idea: Maybe the new package should ship symlinks from the old keymap names to the matching entries of the X11 keymaps? That way we'll get upgraded systems on board, and I can drop more from the translation logic in localed, as everything would be translated implicitly to the new names via symlinks? Vitezslav, any chance we could make that happen?
Oh, and thanks for the fantastic work, much appreciated, this is a big step forward already.
Do we want to quickly throw a feature page together for this as an F19 feature, anyone? The deadline is tomorrow. Just curious if anyone wants to go that way.
(In reply to comment #30) > Do we want to quickly throw a feature page together for this as an F19 > feature, anyone? The deadline is tomorrow. Just curious if anyone wants to > go that way. I am too lazy, I already filed six feature pages. If you guys want to put a page together you are welcome though (but keep it generic...), I'll definitely try to implement everything that's necessary on systemd's side in time for F19.
(In reply to comment #28) > Hmm, regarding the translation table, here's an idea: > > Maybe the new package should ship symlinks from the old keymap names to the > matching entries of the X11 keymaps? That way we'll get upgraded systems on > board, and I can drop more from the translation logic in localed, as > everything would be translated implicitly to the new names via symlinks? > > Vitezslav, any chance we could make that happen? Matching entries should be taken from 'kbd-model-map' file in localed sources, right? Sure, it can be done. But it also means that we have to move "old" console keymaps elsewhere in the very same step. I like "kbd-legacy" from comment#22. My idea is to move all original keymaps to that package (/lib/kbd/keymaps/legacy/). Fonts and unimaps will stay in "kbd-misc" and X11 keymaps will be added there (/lib/kbd/keymaps/xkb/) with symlinks in relevant subdirectories. Any objections?
@ Vitezslav Crhonek, I urge to create a feature page for this. This work needs to be coordinated. Thanks
(In reply to comment #27) > In the long run the xkb stuff will replace all the old console stuff, we > might even step back from using the kernel VT stuff entirely some day and > have a GL system compositor that can draw _real_ fonts and use _real_ input > methods and the xkb keymaps. Today the kernel is limited to show 512 glyphs > at the same time, which is really more a bad joke today for anything but > latin languages. With that step we would also unify the fonts between X and > the console. We really hope we can do better here in the future, but still > on the surface behave like we do today. > > If we get there some day (might be years), the "dumb" kernel VT will then > only be a "debug console" and not be used by any ordinary console user, > unless the box is really broken, and needs debugging. Are you thinking of kmscon here? http://en.wikipedia.org/wiki/Kmscon Do you think it is going in the right direction? David Herrmann announced he was targeting inclusion in Fedora 20 at this year's FOSDEM do you think it is realistic?
> Are you thinking of kmscon here? > http://en.wikipedia.org/wiki/Kmscon Yes, that's what seems like a pretty nice approach. > Do you think it is going in the right direction? It looks nice what he's doing and if we can sort out the issues, it would be a big step forward, and unify all the font, keymap, input method handling on the console with the graphical settings. It would give us a really fast console with all the fancy anti-aliased fonts and such. :) But the main feature would be real unicode support, which can display more than 256(512) glyphs at the same time, which is really needed for non-latin stuff. > David Herrmann announced he > was targeting inclusion in Fedora 20 at this year's FOSDEM do you > think it is > realistic? I don't know. I would be careful with road maps here. There is no need to rush anything really. If the stuff is ready, we can certainly try. I doubt it will be the default in F20, but who knows. :)
(In reply to comment #32) > (In reply to comment #28) > > Hmm, regarding the translation table, here's an idea: > > > > Maybe the new package should ship symlinks from the old keymap names to the > > matching entries of the X11 keymaps? That way we'll get upgraded systems on > > board, and I can drop more from the translation logic in localed, as > > everything would be translated implicitly to the new names via symlinks? > > > > Vitezslav, any chance we could make that happen? > > Matching entries should be taken from 'kbd-model-map' file in localed > sources, right? Sure, it can be done. Yes! > But it also means that we have to move "old" console keymaps elsewhere in > the very same step. Yeah, a subdirectory should suffice. > I like "kbd-legacy" from comment#22. My idea is to move all original keymaps > to that package (/lib/kbd/keymaps/legacy/). Fonts and unimaps will stay in > "kbd-misc" and X11 keymaps will be added there (/lib/kbd/keymaps/xkb/) with > symlinks in relevant subdirectories. Any objections? Sounds good to me!
So we didn't get a feature page for this, but I still think it would be really nice if we could just hook it up for F19. It sounds like we have a plan for the kbd changes, but the changes haven't actually been done yet. Then we need to figure out what to do at the higher levels: systemd/localed, anaconda, and config tool levels. It would be nice to have this done in time for F19 Alpha, or Beta at least, and it doesn't seem like it's a huge amount of work; would it be possible for people to get together and just bash this out?
(In reply to comment #37) > > It sounds like we have a plan for the kbd changes, but the changes haven't > actually been done yet. > First attempt is available there: http://vcrhonek.fedorapeople.org/kbd/kbd-1.15.5-6.fc19.src.rpm However, symlinks (from original console keymap to converted X11 keymap) should be reviewed by users from respective countries. Basically xlayout should be fine, but xvariant is probably wrong in many cases (and I believe that sometimes it doesn't exist at all).
you could just go with the behaviour systemd had in F18. It's wrong in some cases, but at least it'd be the _same_ wrongness, and trying to make them all as right as possible would be a bit of an endeavour.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Adding 'FutureFeature' keyword to note this as an RFE. Are we getting any further with this? Vitezslav, were you waiting on testing?
This is still high up on my todo list, but given that font laoding and stuff was broken in the kernel recently I never started working on it...
(In reply to comment #41) > Adding 'FutureFeature' keyword to note this as an RFE. Are we getting any > further with this? Vitezslav, were you waiting on testing? Yes, I am. But maybe now it's good time to test it in Rawhide? If I temporarily force installation of -legacy subpackage, everyone will be able to loadkey original keymaps in case of emergency... Or could it cause something really wrong?
That sounds like a good plan. It certainly could cause something really wrong, but that's what we have Rawhide for. =) Just so long as you're ready with the clean-up kit if it does. I did mail the i18n list and ask them to take a look at this bug, but I didn't get much feedback.
So I'm running Rawhide now. The xkb-derived layouts certainly exist in /usr/lib/kbd/xkb , and I can do for e.g. 'loadkeys fr-oss' and get something that seems like fr-oss. I did notice that localectl is still 'converting' to the old kbd layouts, so I filed a bug on that: https://bugzilla.redhat.com/show_bug.cgi?id=981805 What else needs testing?
So as of F20 Final TC1, 981805 is still a problem, and we have https://bugzilla.redhat.com/show_bug.cgi?id=1028207 . One thing I'm not clear on is how we are handling the case where people switch between layouts. AIUI, in the 'old' kbd layouts, where it was commonly necessary to switch between, say, Russian and US layouts, the 'ru' layout would contain both Russian and US layouts and define a switcher key. In the xkb world, you're expected to configure both a Russian and US layout as available and set up an xkb key combination for switching layouts. So how do we handle that, with the xkb-converted kbd layouts? Have the converted layouts been fiddled so that, where appropriate, they contain multiple layouts and a switcher key definition? Or what?
(In reply to Adam Williamson from comment #46) > AIUI, in the 'old' kbd layouts, where it was > commonly necessary to switch between, say, Russian and US layouts, the 'ru' > layout would contain both Russian and US layouts and define a switcher key. And that does not scale because only the "commonly" (for weird us-oriented "common" cases) were defined this way and there are already too many layouts to hope create pre-defined combos of all of them. Switcing really needs a specific toggle
Nic: the thing is, I don't know if kbd is actually capable of the concept of 'have multiple separate layouts loaded and a key for switching between them' in the way xkb is.
(In reply to Adam Williamson from comment #48) > Nic: the thing is, I don't know if kbd is actually capable of the concept of > 'have multiple separate layouts loaded and a key for switching between them' > in the way xkb is. I don't know either but I do know that combo layouts are no substitute. And I did grow up in a translator house helping mom set up the most improbable systems to convince her computer to write more than one script.
If that's all kbd does then that's all we have to work with, unless you want to extend kbd.
(In reply to Adam Williamson from comment #48) > Nic: the thing is, I don't know if kbd is actually capable of the concept of > 'have multiple separate layouts loaded and a key for switching between them' > in the way xkb is. I'm afraid it is not capable of it. loadkeys is just one-shot utility.
Another thing - it would be nice to be able to load "legacy" keymap on boot somehow. I thought that giving full path to KEYMAP variable would do the trick, but it does not. E.g. # cat /etc/vconsole.conf KEYMAP="/lib/kbd/keymaps/legacy/i386/qwerty/cz-lat2.map.gz" FONT="latarcyrheb-sun16" Then after reboot (and "systemctl restart systemd-vconsole-setup" because of bz#1028207) localectl shows: # localectl System Locale: LANG=en_US.UTF-8 VC Keymap: /lib/kbd/keymaps/legacy/i386/qwerty/cz-lat2.map.gz X11 Layout: us But cz-lat2 from /lib/kbd/keymaps/i386/qwerty/cz-lat2.map.gz (which is symlink to /lib/kbd/keymaps/xkb/cz-qwerty.map.gz) is actually loaded.
So, uh, our behaviour here is currently clearly pretty broken. We took 'legacy' out of the path, but systemd-logind will still 'convert' any layout that /usr/share/systemd/kbd-model-map has a mapping for to the legacy name. And we haven't solved the problem of console switchable layouts with the xkb-converted layout set, it seems. And we have a couple of incidental bugs in layout loading. Seems like the chances of you getting an undesirable result OOTB if your layout isn't 'US' are pretty high, as things stand.
(In reply to Adam Williamson from comment #53) > So, uh, our behaviour here is currently clearly pretty broken. > > We took 'legacy' out of the path, but systemd-logind will still 'convert' > any layout that /usr/share/systemd/kbd-model-map has a mapping for to the > legacy name. And we haven't solved the problem of console switchable layouts > with the xkb-converted layout set, it seems. And we have a couple of > incidental bugs in layout loading. But that's why there are symlinks from those legacy names (/lib/kbd/keymaps/i386) to real xkb converted keymaps (/lib/kbd/xkb)... When switchable layout is need, then the best way is probably to use legacy keymap. (Or modify converted xkb keymaps, but... if you look at them, the result of conversion is not very human readable file.) > > Seems like the chances of you getting an undesirable result OOTB if your > layout isn't 'US' are pretty high, as things stand.
"But that's why there are symlinks from those legacy names (/lib/kbd/keymaps/i386) to real xkb converted keymaps (/lib/kbd/xkb)..." It's still crazy behaviour, though: user selects an X11 keymap in anaconda, localed 'translates' it into a console keymap which is then symlinked back to the X11-converted keymap. Why bother going around in circles? I think the reason for the symlinks is really to handle people upgrading systems which already have a 'legacy' name in /etc/vconsole.conf , but for fresh installs, if we want the user to be using a converted-xkb map, we should actually be writing that directly into the config, not going through two levels of unnecessary indirection. We have https://bugzilla.redhat.com/show_bug.cgi?id=1031848 to track the switchable-layout problem now.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I don't think having this bug open is serving any purpose at this point, the change got done and it's broadly been working.