Bug 837292 - console-setup integration with systemd
console-setup integration with systemd
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: 743281
  Show dependency treegraph
 
Reported: 2012-07-03 07:37 EDT by Vitezslav Crhonek
Modified: 2015-01-09 12:24 EST (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-09 12:24:36 EST
Type: Bug
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 Vitezslav Crhonek 2012-07-03 07:37:31 EDT
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
Comment 1 Lennart Poettering 2012-07-03 11:06:11 EDT
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?
Comment 2 Vitezslav Crhonek 2012-07-04 04:21:17 EDT
(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.
Comment 3 Bill Nottingham 2012-08-08 16:57:14 EDT
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.
Comment 4 Kay Sievers 2012-08-08 18:21:35 EDT
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.
Comment 5 Vratislav Podzimek 2012-08-16 07:07:49 EDT
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?
Comment 6 Lennart Poettering 2012-08-16 14:03:40 EDT
(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
Comment 7 Vratislav Podzimek 2012-08-22 05:11:43 EDT
(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.
Comment 8 Lennart Poettering 2012-08-22 07:43:48 EDT
(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.
Comment 9 Vratislav Podzimek 2012-08-22 08:56:23 EDT
(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).
Comment 10 Lennart Poettering 2012-08-22 21:34:21 EDT
(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.
Comment 11 Vratislav Podzimek 2012-10-11 07:16:57 EDT
(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.
Comment 12 Adam Williamson 2012-12-21 19:40:20 EST
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.
Comment 13 Ray Strode [halfline] 2013-01-02 14:50:11 EST
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.
Comment 14 Ray Strode [halfline] 2013-01-02 14:56:33 EST
(if having a BuildRequires: xkeyboard-config is problematic, you could just stuff the xkeyboard-config source tarball into the package too, I guess)
Comment 15 Vitezslav Crhonek 2013-01-08 05:11:24 EST
(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?
Comment 16 Ray Strode [halfline] 2013-01-08 14:50:32 EST
yea makes sense to me. You could probably just put them in kbd-misc
Comment 17 Adam Williamson 2013-01-08 17:34:49 EST
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?
Comment 18 Ray Strode [halfline] 2013-01-09 11:14:58 EST
that's what this bug is about primarily
Comment 19 Adam Williamson 2013-01-11 17:53:56 EST
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.
Comment 20 Vitezslav Crhonek 2013-01-17 06:01:44 EST
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.
Comment 21 Vitezslav Crhonek 2013-01-17 06:04:13 EST
(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.
Comment 22 Lennart Poettering 2013-01-17 14:19:07 EST
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?
Comment 23 Ray Strode [halfline] 2013-01-17 14:48:28 EST
hey awesome work! thanks.  seems to work okay in my brief testing.
I was able to do loadkeys us-alt-intl and then type í
Comment 24 Ray Strode [halfline] 2013-01-17 14:48:56 EST
maybe instead of x-converted, call it xkeyboard-config
Comment 25 Lennart Poettering 2013-01-17 14:54:24 EST
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".
Comment 26 Adam Williamson 2013-01-24 18:56:31 EST
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.
Comment 27 Kay Sievers 2013-01-24 21:05:21 EST
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.
Comment 28 Lennart Poettering 2013-01-24 22:16:36 EST
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?
Comment 29 Lennart Poettering 2013-01-24 22:17:12 EST
Oh, and thanks for the fantastic work, much appreciated, this is a big step forward already.
Comment 30 Adam Williamson 2013-01-28 19:58:24 EST
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.
Comment 31 Lennart Poettering 2013-01-28 21:41:25 EST
(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.
Comment 32 Vitezslav Crhonek 2013-01-29 06:07:57 EST
(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?
Comment 33 Rahul Sundaram 2013-01-29 13:15:52 EST
@ Vitezslav Crhonek,  I urge to create a feature page for this.  This work needs to be coordinated.   Thanks
Comment 34 Nicolas Mailhot 2013-02-04 09:29:22 EST
(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?
Comment 35 Kay Sievers 2013-02-04 09:37:53 EST
> 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. :)
Comment 36 Lennart Poettering 2013-02-04 12:58:46 EST
(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!
Comment 37 Adam Williamson 2013-02-26 14:29:43 EST
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?
Comment 38 Vitezslav Crhonek 2013-03-05 08:09:45 EST
(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).
Comment 39 Adam Williamson 2013-03-06 02:40:21 EST
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.
Comment 40 Fedora End Of Life 2013-04-03 13:44:50 EDT
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
Comment 41 Adam Williamson 2013-05-08 14:40:34 EDT
Adding 'FutureFeature' keyword to note this as an RFE. Are we getting any further with this? Vitezslav, were you waiting on testing?
Comment 42 Lennart Poettering 2013-05-09 08:47:45 EDT
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...
Comment 43 Vitezslav Crhonek 2013-05-13 10:00:14 EDT
(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?
Comment 44 Adam Williamson 2013-05-13 11:14:31 EDT
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.
Comment 45 Adam Williamson 2013-07-05 17:27:01 EDT
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?
Comment 46 Adam Williamson 2013-11-16 20:29:38 EST
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?
Comment 47 Nicolas Mailhot 2013-11-17 04:33:12 EST
(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
Comment 48 Adam Williamson 2013-11-17 13:51:03 EST
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.
Comment 49 Nicolas Mailhot 2013-11-17 16:33:24 EST
(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.
Comment 50 Adam Williamson 2013-11-17 18:18:14 EST
If that's all kbd does then that's all we have to work with, unless you want to extend kbd.
Comment 51 Vitezslav Crhonek 2013-11-18 07:15:15 EST
(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.
Comment 52 Vitezslav Crhonek 2013-11-18 08:00:59 EST
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.
Comment 53 Adam Williamson 2013-11-18 11:25:07 EST
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.
Comment 54 Vitezslav Crhonek 2013-11-19 03:55:14 EST
(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.
Comment 55 Adam Williamson 2013-11-19 12:33:38 EST
"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.
Comment 56 Fedora End Of Life 2015-01-09 12:13:57 EST
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.
Comment 57 Adam Williamson 2015-01-09 12:24:36 EST
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.

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