Bug 981805

I'm convinced that we should rip out all this magic and handle only the
xkb keymaps.

Any possibly needed compat, we should provide by symlinks, not by
the static list we ship currently.

That would certainly be the simplest plan. How would we handle upgrades?

(I haven't checked if there are actually any keymap names that exist in the 'old kbd' set but not the 'new xkb' set, but it seems possible).

I just want to mention that resolving this bug would help Anaconda a lot.

Kay, any update on this?

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

systemd folks, we would really appreciate if this can be addressed ASAP. It already looks like it'll miss F20 Alpha. We really need to have the 'new' keyboard handling hooked up as it's intended to work by Beta, so we can test it and not be trying to write and test it on the fly for final.

This bug seems like a good place to mention a problem I'm having with the new keyboard process in F20.

I run a unique custom keymap (ergonomic).  In the past, I've just copied the two keymap files (same keymap, one for console, one for X) into the appropriate places, changed the appropriate configuration files, and was good to go.  Tweak once at install, then never have to touch anything again.

It was pretty easy to tweak X to accept the keymap in F20, a return to the days when the evdev.xml and base.xml files were used.  Put the custom keymap file in xkb/symbols and a stanza for it in the xml files in xkb/rules, and in business.  I made it default by using a file in /usr/share/X11/xorg.conf.d, though I usually use a .Xkbmap file in my home directory.  Unfortunately, since I am unable to officially install F20 because of an obscure bug in the image, I used unconventional manual means, and can't login for now.  But no matter what I do, I can't get systemd to accept my custom console file.  I put the name in /etc/vconsole.conf (the replacement for /etc/sysconfig/keyboard), and it ignores it.  I suspect that it isn't actually reading the /lib/kbd/keymaps/xkb directory to see which keymaps are present, but is instead looking at a fixed internal list derived from approved X keymappings.  And since my custom keymap isn't on that approved list, it's ignored and systemd defaults to us.

Would it be possible to have systemd look at the keymaps present for the console, so people who want to run unique custom keymaps can do so?  Or maybe, it could be added to a conf file somewhere.  Or perhaps there is already a way to do this, and I'm not just aware of it yet.  If so, please tell me.

Thanks.

"This bug seems like a good place to mention a problem I'm having with the new keyboard process in F20."

No, it isn't. One bug report per bug. Please file yours separately.

Do you consider my problem a bug?  I thought of it more as a possible flaw in the design.  The process hasn't even been finalized yet.  :-)  

I filed a bug against systemd.

https://bugzilla.redhat.com/show_bug.cgi?id=1010516

This still seems to be broken in current F20: when you select UK English keyboard layout, vconsole.conf is written as:

KEYMAP="uk"

which is the old, kbd "UK" layout. The new, xkb one would be "gb". This implies that localed is still 'converting' xkb layout names to kbd ones, whereas we don't want it to any more.

Created attachment 825795 [details]
systemd patch to prefer converted keymaps to legacy ones

This patch should fix the cases described in the bug, X11's fr-oss will be mapped to fr-oss, gb to gb. The patch is not complete, because the mapping the other way is asymmetrical now, but maybe that's not so important now.

It would be great if somebody could look over the general logic of the change.

(In reply to Kay Sievers from comment #1)
> I'm convinced that we should rip out all this magic and handle only the
> xkb keymaps.
> 
> Any possibly needed compat, we should provide by symlinks, not by
> the static list we ship currently.
I think it's too late before F20 to do major changes. Let's just fix stuff, and then let's remove the legacy logic from systemd totally. Removing it totally would mean that *setting* keymaps through legacy names would stop working. But *using* previously configured keymaps with legacy names should continue to work.

That sounds like a sensible change so far as it goes. Honestly, the issue that worries me the most is https://bugzilla.redhat.com/show_bug.cgi?id=837292#c46 , though - and I can't think of an immediately good way to deal with that that would be safe for the short horizon we have before F20. Especially if, as vitezslav seems to suggest, it turns out there actually isn't any way to cause the 'legacy' layouts to be loaded if they're not in the loadkeys path.

(In reply to Adam Williamson from comment #14)
> That sounds like a sensible change so far as it goes. Honestly, the issue
> that worries me the most is
> https://bugzilla.redhat.com/show_bug.cgi?id=837292#c46 ,
Exactly. That's why removing 'legacy' layouts isn't much of an option. I sincerely doubt that anyone's going to come up with a solution... Let's just wait a bit more until the console is obsolete for everything except being used as a debug tool.

Patch applied in http://cgit.freedesktop.org/systemd/systemd/commit/?id=0732ef7. I'll be putting out an update soon.

For the record, filed https://bugzilla.redhat.com/show_bug.cgi?id=1031848 for the switchable layout problem.

For F20, I think the best gameplan would be to get this patch and the kbd change from https://bugzilla.redhat.com/show_bug.cgi?id=1028207 both built and included ASAP, come up with some kind of ugly hack for the layouts we know should use legacy switchable kbd layouts not xkb-converted ones, and for the longer-term, just focus on getting kmscon into Fedora.

I did a test live image build with systemd-208-5.fc21, but the fix for this either wasn't correctly included or didn't work. 'localectl set-x11-keymap gb' still gives me 'uk' as the 'VC Keymap' and in /etc/vconsole.conf, not 'gb'.

(the systemd-208-5.fc21 build 'failed', but both x86-64 and i686 succeeded; it was only ARM that failed. I was able to get the x86_64 packages out of the koji task.)

> I did a test live image build with systemd-208-5.fc21
Sorry, I screwed up and included only patches 1-99, missing 100-117 :)
Then I too was confused why it's not working. systemd-208-6.fc21 or systemd-208-6.fc20 should be fine. They are basically the same, except that systemd-208-6.fc20 has the dependency on kmod >= 15 reverted.

systemd-208-6.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/systemd-208-6.fc20

aha, thanks! I'll rebuild my live image and re-test.

btw, you could ask kay to push kmod 15 stable for f20: it's been in updates-testing forever and has +10 karma, but he didn't set an auto-stable-push karma threshold and has not pushed it manually.

remark on the fix, btw: I don't know if it's possible, but could localed ask xkb for its search path, rather than having what it hopes is the same search path coded in? (KBD_KEYMAP_DIRS)

Yeah, that's a bit ugly. Maybe kbd could provide a pkgconfig file with the search path?

OK, with 208-6, I confirm the fix, and with this combined with a kbd with vitezslav's and my fixes for other issues, overall behaviour looks sane.

Package systemd-208-6.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-208-6.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-21935/systemd-208-6.fc20
then log in and leave karma (feedback).

systemd-208-6.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.