Hello list,
what is the expected way of handling X11 keyboard layouts in Fedora 18?
I don't use xorg.conf, the configuration was autodetected from /etc/sysconfig/keyboard (probably) till F17 and it worked just fine. After upgrading to F18 using yum method, my keyboard layout stopped working.
Should the X11 server (or login managers) autodetect the layout from new config files? Or is 'localectl set-x11-keymap' the only supported way now?
If 'localectl' is the only supported way, we should add this information to "Upgrading Fedora using yum" instructions on the wiki. The same with old kernel options. (I do not know how is this handled in the other upgrade methods.)
If the old configuration files are supposed to work, what is the responsible component I should file bug on?
Jan
On 11/30/2012 01:33 PM, Jan Včelák wrote:
Hello list,
what is the expected way of handling X11 keyboard layouts in Fedora 18?
I don't use xorg.conf, the configuration was autodetected from /etc/sysconfig/keyboard (probably) till F17 and it worked just fine. After upgrading to F18 using yum method, my keyboard layout stopped working.
Should the X11 server (or login managers) autodetect the layout from new config files? Or is 'localectl set-x11-keymap' the only supported way now?
If 'localectl' is the only supported way, we should add this information to "Upgrading Fedora using yum" instructions on the wiki. The same with old kernel options. (I do not know how is this handled in the other upgrade methods.)
If the old configuration files are supposed to work, what is the responsible component I should file bug on?
Jan
I guess now is used /etc/vconsole.conf. Could you add it into upgrade page if it works for you? Imho it's related to my previous question: https://fedorahosted.org/fesco/ticket/963
Marcela
On Friday 30 of November 2012 14:06:03, Marcela Mašláňová wrote:
I guess now is used /etc/vconsole.conf. Could you add it into upgrade page if it works for you? Imho it's related to my previous question: https://fedorahosted.org/fesco/ticket/963
OK, I added an additional step to the instructions: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_17_-.3E_Fed...
Unfortunatelly, the step cannot be just copy-pasted. Feel free to review and improve it. ;-)
Jan
On Sex, 2012-11-30 at 14:51 +0100, Jan Včelák wrote:
On Friday 30 of November 2012 14:06:03, Marcela Mašláňová wrote:
I guess now is used /etc/vconsole.conf. Could you add it into upgrade page if it works for you? Imho it's related to my previous question: https://fedorahosted.org/fesco/ticket/963
OK, I added an additional step to the instructions: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_17_-.3E_Fed...
system-config-keyboard should do this:
1. Get the old settings: cat /etc/sysconfig/keyboard 2. Set the new settings: su -c 'localectl set-x11-keymap <layout> [<model>] [<variant>] [<options>]' 3. Remove the old configuration file: su -c 'rm /etc/sysconfig/keyboard'
or at least warning that we should do something new like this .
Unfortunatelly, the step cannot be just copy-pasted. Feel free to review and improve it. ;-)
Jan
On Saturday 01 December 2012 23:38:49 Sérgio Basto wrote:
system-config-keyboard should do this:
1. Get the old settings: cat /etc/sysconfig/keyboard 2. Set the new settings: su -c 'localectl set-x11-keymap <layout> [<model>] [<variant>] [<options>]' 3. Remove the old configuration file: su -c 'rm /etc/sysconfig/keyboard'
Replace item 3. with an even better one: 3. Overwrite /etc/sysconfig/keyboard with following content: # This file is obsolete and may be removed, its settings # were migrated on <date> by running: # localectl set-x11-keymap....
Thus, making people understand what happened to their old file.
On Dom, 2012-12-02 at 19:33 +0200, Oron Peled wrote:
On Saturday 01 December 2012 23:38:49 Sérgio Basto wrote:
system-config-keyboard should do this:
- Get the old settings: cat /etc/sysconfig/keyboard
- Set the new settings: su -c 'localectl set-x11-keymap <layout>
[<model>] [<variant>] [<options>]'
- Remove the old configuration file: su -c
'rm /etc/sysconfig/keyboard'
Replace item 3. with an even better one:
- Overwrite /etc/sysconfig/keyboard with following content:
# This file is obsolete and may be removed, its settings
# were migrated on <date> by running:
# localectl set-x11-keymap....
Thus, making people understand what happened to their old file.
I agree .
Thanks,
On Sun, Dec 2, 2012 at 12:38 AM, Sérgio Basto sergio@serjux.com wrote:
system-config-keyboard should do this:
1. Get the old settings: cat /etc/sysconfig/keyboard 2. Set the new settings: su -c 'localectl set-x11-keymap <layout> [<model>] [<variant>] [<options>]' 3. Remove the old configuration file: su -c 'rm /etc/sysconfig/keyboard'or at least warning that we should do something new like this .
http://pkgs.fedoraproject.org/cgit/systemd.git/commit/?h=f18&id=0969ad24... already attempts to do some kind of automatic conversion. If that is insufficient, please file bugs against systemd. Mirek
On 12/02/2012 10:57 PM, Miloslav Trmač wrote:
On Sun, Dec 2, 2012 at 12:38 AM, Sérgio Basto sergio@serjux.com wrote:
system-config-keyboard should do this:
1. Get the old settings: cat /etc/sysconfig/keyboard 2. Set the new settings: su -c 'localectl set-x11-keymap <layout> [<model>] [<variant>] [<options>]' 3. Remove the old configuration file: su -c 'rm /etc/sysconfig/keyboard'or at least warning that we should do something new like this .
http://pkgs.fedoraproject.org/cgit/systemd.git/commit/?h=f18&id=0969ad24... already attempts to do some kind of automatic conversion. If that is insufficient, please file bugs against systemd.
It seems that the virtual console layout is migrated ok, but the x11 part is not. This is what I get on my two upgraded F18 boxes:
[root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: n/a [root@turre ~]#
The "n/a" part is the "problem" as it falls back to US keyboard. localectl manual says both set-keymap and set-x11-keymap apply to both the keymaps unless --no-convert is specified, but that doesn't seem to happen in practise:
[root@turre ~]# localectl set-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: n/a [root@turre ~]# localectl set-x11-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi-latin1 X11 Layout: fi [root@turre ~]# localectl set-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: fi X11 Model: pc105 X11 Options: terminate:ctrl_alt_bksp
It's a bit bizarre: set-keymap doesn't seem to find "fi" as the closest matching keyboard for x11 (it probably should), set-x11-keymap considers "fi-latin1" to be the closest matching keymap for "fi", but in this specific order its possible to get both set to "fi". Only it now adds additional model + options there, whatever the reason.
- Panu -
On Mon, 2012-12-03 at 09:20 +0200, Panu Matilainen wrote:
On 12/02/2012 10:57 PM, Miloslav Trmač wrote:
On Sun, Dec 2, 2012 at 12:38 AM, Sérgio Basto sergio@serjux.com wrote:
system-config-keyboard should do this:
1. Get the old settings: cat /etc/sysconfig/keyboard 2. Set the new settings: su -c 'localectl set-x11-keymap <layout> [<model>] [<variant>] [<options>]' 3. Remove the old configuration file: su -c 'rm /etc/sysconfig/keyboard'or at least warning that we should do something new like this .
http://pkgs.fedoraproject.org/cgit/systemd.git/commit/?h=f18&id=0969ad24... already attempts to do some kind of automatic conversion. If that is insufficient, please file bugs against systemd.
It seems that the virtual console layout is migrated ok, but the x11 part is not. This is what I get on my two upgraded F18 boxes:
[root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: n/a [root@turre ~]#
The "n/a" part is the "problem" as it falls back to US keyboard. localectl manual says both set-keymap and set-x11-keymap apply to both the keymaps unless --no-convert is specified, but that doesn't seem to happen in practise:
[root@turre ~]# localectl set-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: n/a [root@turre ~]# localectl set-x11-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi-latin1 X11 Layout: fi [root@turre ~]# localectl set-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: fi X11 Model: pc105 X11 Options: terminate:ctrl_alt_bksp
It's a bit bizarre: set-keymap doesn't seem to find "fi" as the closest matching keyboard for x11 (it probably should), set-x11-keymap considers "fi-latin1" to be the closest matching keymap for "fi", but in this specific order its possible to get both set to "fi". Only it now adds additional model + options there, whatever the reason.
- Panu -
The "conversion" (as systemd-localed calls it) works really poorly also for the Czech keymaps/layouts. 'cz' X11 layout is "converted" to 'cz-lat2' which works like 'us' until you hit the "Pause Break" key. This is really unfortunate especially when people set their LUKS password in Anaconda with the 'cz' X11 layout activated and then they are supposed to enter it again with the 'cz-lat2' keymap during boot.
On Mon, 03.12.12 10:04, Vratislav Podzimek (vpodzime@redhat.com) wrote:
The "conversion" (as systemd-localed calls it) works really poorly also for the Czech keymaps/layouts. 'cz' X11 layout is "converted" to 'cz-lat2' which works like 'us' until you hit the "Pause Break" key. This is really unfortunate especially when people set their LUKS password in Anaconda with the 'cz' X11 layout activated and then they are supposed to enter it again with the 'cz-lat2' keymap during boot.
This mapping is based on /usr/share/systemd/kbd-model-map btw which we stole from anaconda (or was it s-s-k?). When converting a console kbd map to an X11 kdb map timedated/timedatectl will go through the list and take the first line that matches. If we go the other way, then we will look for the line where the most components match and if multiple lines apply equally well, then we pick the earliest one.
So the general rule is: pick the best matching choice, and if in doubt take the earlier one.
We are happy to take patches for this database file, to improve the mapping. Please send git patches to the systemd ML.
Thanks,
Lennart
Le Mer 19 décembre 2012 22:57, Lennart Poettering a écrit :
On Mon, 03.12.12 10:04, Vratislav Podzimek (vpodzime@redhat.com) wrote:
The "conversion" (as systemd-localed calls it) works really poorly also for the Czech keymaps/layouts. 'cz' X11 layout is "converted" to 'cz-lat2' which works like 'us' until you hit the "Pause Break" key. This is really unfortunate especially when people set their LUKS password in Anaconda with the 'cz' X11 layout activated and then they are supposed to enter it again with the 'cz-lat2' keymap during boot.
This mapping is based on /usr/share/systemd/kbd-model-map btw which we stole from anaconda (or was it s-s-k?).
Unfortunately this mapping never worked well, is full of obsolete entries, has been a PITA to get updated for at least a decade (bugzilla change requests got ignored for years). Its only redeemable feature was that once you had installed your system you could fix anaconda choices in sysconfig files and forget about this particular i18n horror story (good i18n is much less important server-side which explains why anaconda layout support was 'good enough' for RHAT I guess)
kbd layout database has fallen into disrepair since ubuntu/debian started generating their console layouts from xkb-config (they don't use kbd).
Ubuntu/debian has the lion share desktop-side so all the i18n layouts get improved and updated in xkb-config, and few layout authors even bother with kbd layouts anymore (writing a layout is akin to writing in assembler, no one once to write the same routine twice it two different obscure layout dialects if it's possible to avoid it)
We are happy to take patches for this database file, to improve the mapping.
The database is bitrotten and even it it wasn't most modern layouts do not exist kbd-side at all. Most layouts with perfect mapping are old legacy ascii layouts. They are still in xkb-config for historical reasons but in many locales the preferred layout includes changes (unicode…) which have never been ported to kbd.
If you really want to support console keyboard layouts in systemd, you need to start generating console layouts from xkb-config, not adopt the old anaconda mapping bandaid
Hi,
On Thu, Dec 20, 2012 at 1:05 PM, Nicolas Mailhot wrote:
If you really want to support console keyboard layouts in systemd, you need to start generating console layouts from xkb-config, not adopt the old anaconda mapping bandaid
Can you file a bug report against Anaconda and systemd?
Rahul
Le Jeu 20 décembre 2012 19:32, Rahul Sundaram a écrit :
Hi,
On Thu, Dec 20, 2012 at 1:05 PM, Nicolas Mailhot wrote:
If you really want to support console keyboard layouts in systemd, you need to start generating console layouts from xkb-config, not adopt the old anaconda mapping bandaid
Can you file a bug report against Anaconda and systemd?
IIRC, an anaconda bug already exists (don't remember the number, I do remember answering some questions Mismo asked about the Debian system there)
I haven't checked for a long time if the bug about anaconda French layout mappings has been finally processed.
On Thu, Dec 20, 2012 at 3:49 PM, Sérgio Basto sergio@serjux.com wrote:
On Qui, 2012-12-20 at 20:16 +0100, Nicolas Mailhot wrote:
IIRC, an anaconda bug already exists (don't remember the number, I do remember answering some questions Mismo asked about the Debian system there)
I need the number
https://bugzilla.redhat.com/show_bug.cgi?id=680990
and
Nicolas Mailhot (nicolas.mailhot@laposte.net) said:
If you really want to support console keyboard layouts in systemd, you need to start generating console layouts from xkb-config, not adopt the old anaconda mapping bandaid
There's already a bug for this, but the runtime perl dependencies it introduced were deemed too much, as I recall.
Bill
Le Jeu 20 décembre 2012 20:04, Bill Nottingham a écrit :
Nicolas Mailhot (nicolas.mailhot@laposte.net) said:
If you really want to support console keyboard layouts in systemd, you need to start generating console layouts from xkb-config, not adopt the old anaconda mapping bandaid
There's already a bug for this, but the runtime perl dependencies it introduced were deemed too much, as I recall.
The alternative would be to pre-generate console layouts in an xkb-config subpackage, but I guess that would be a lot of data given how modular xkb-config is nowadays. One way or another, correct console i18n is going to be more expensive than the limited choices in the kbd layout database.
On Thu, 20.12.12 19:05, Nicolas Mailhot (nicolas.mailhot@laposte.net) wrote:
The "conversion" (as systemd-localed calls it) works really poorly also for the Czech keymaps/layouts. 'cz' X11 layout is "converted" to 'cz-lat2' which works like 'us' until you hit the "Pause Break" key. This is really unfortunate especially when people set their LUKS password in Anaconda with the 'cz' X11 layout activated and then they are supposed to enter it again with the 'cz-lat2' keymap during boot.
This mapping is based on /usr/share/systemd/kbd-model-map btw which we stole from anaconda (or was it s-s-k?).
Unfortunately this mapping never worked well, is full of obsolete entries, has been a PITA to get updated for at least a decade (bugzilla change requests got ignored for years). Its only redeemable feature was that once you had installed your system you could fix anaconda choices in sysconfig files and forget about this particular i18n horror story (good i18n is much less important server-side which explains why anaconda layout support was 'good enough' for RHAT I guess)
Happy to take patches to improve this list.
kbd layout database has fallen into disrepair since ubuntu/debian started generating their console layouts from xkb-config (they don't use kbd).
Hmm, are you saying that Fedora is just freeloading off Ubuntu? Interesting, usually one hears only the opposite...
Ubuntu/debian has the lion share desktop-side so all the i18n layouts get improved and updated in xkb-config, and few layout authors even bother with kbd layouts anymore (writing a layout is akin to writing in assembler, no one once to write the same routine twice it two different obscure layout dialects if it's possible to avoid it)
Well, the conversion stuff is really nothing we'd want to adopt in Fedora as is. It's a perl hackery around the awful old tools we use. Yes, it would be great if we could also use the same mappings for the console as for X, but that would either require that somehow the conversions can be done offline and shipped pre-converted, or that somebody reimplements this in a sane toolset that isn't just some Perl hackery.
We are happy to take patches for this database file, to improve the mapping.
The database is bitrotten and even it it wasn't most modern layouts do not exist kbd-side at all. Most layouts with perfect mapping are old legacy ascii layouts. They are still in xkb-config for historical reasons but in many locales the preferred layout includes changes (unicode…) which have never been ported to kbd.
I doubt it's that rotten. It definitely works fine for the most popular keymaps, such as the american and german.
Note that this conversion has been exposed via GNOME's kbd config thingy for a while, and we didn't really get much bugs about it, hence I assume that it isn't too bad.
I mean, if you see bugs, please report them, tell us what to fix. Other than that i can only tell you that the amount of bugs we got so far about this is close to zero, hence I can only assume things are not as bad as you say.
If you really want to support console keyboard layouts in systemd, you need to start generating console layouts from xkb-config, not adopt the old anaconda mapping bandaid
I am pretty sure I don't want to work on this. But I'd welcome if somebody did work on it, and we'd be happy to support this in systemd if done right.
Lennart
On Fri, 2012-12-21 at 16:57 +0100, Lennart Poettering wrote:
The database is bitrotten and even it it wasn't most modern layouts do not exist kbd-side at all. Most layouts with perfect mapping are old legacy ascii layouts. They are still in xkb-config for historical reasons but in many locales the preferred layout includes changes (unicode…) which have never been ported to kbd.
I doubt it's that rotten. It definitely works fine for the most popular keymaps, such as the american and german.
All this keymap stuff is bending my brain, but I've been poking at it for the last few days, and I'm rather afraid it *is* that bad. See this tentatively accepted blocker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=889562
If I have everything right, anaconda is offering a keymap list that it derives from xkb. I'm having trouble counting precisely how many layouts it offers, but it looks to be definitely over 400.
According to 'localectl list-keymaps', systemd-localed has mappings for 209 keymaps.
So there's at least 191 keymaps (probably rather more) which anaconda offers you but which systemd doesn't understand: if you install with any of these keymaps selected as the default keymap (top of the list in Keyboard spoke), you will wind up with US as your console keyboard layout on the installed system.
We could really do with input from interested parties on exactly how bad of a problem this is - if people could look through the keyboard layouts offered in F18's Keyboard spoke and compare them to the list from 'localectl list-keymaps', and identify particularly important ones that systemd doesn't seem to grok, it'd really help.
So far, I _think_ systemd is missing all Arabic layouts. It's missing French (Canada). It's missing five Japanese layouts that anaconda offers. It's missing Chinese, that's a big one. That's just scratching the surface.
Note that this conversion has been exposed via GNOME's kbd config thingy for a while, and we didn't really get much bugs about it, hence I assume that it isn't too bad.
I mean, if you see bugs, please report them, tell us what to fix. Other than that i can only tell you that the amount of bugs we got so far about this is close to zero, hence I can only assume things are not as bad as you say.
It's more likely to be that we have so many keymap bugs, everyone's confused about what bug is what. That's certainly where I feel like we're at right now.
If you really want to support console keyboard layouts in systemd, you need to start generating console layouts from xkb-config, not adopt the old anaconda mapping bandaid
I am pretty sure I don't want to work on this. But I'd welcome if somebody did work on it, and we'd be happy to support this in systemd if done right.
Lennart
-- Lennart Poettering - Red Hat, Inc.
On Fri, 21.12.12 16:11, Adam Williamson (awilliam@redhat.com) wrote:
On Fri, 2012-12-21 at 16:57 +0100, Lennart Poettering wrote:
The database is bitrotten and even it it wasn't most modern layouts do not exist kbd-side at all. Most layouts with perfect mapping are old legacy ascii layouts. They are still in xkb-config for historical reasons but in many locales the preferred layout includes changes (unicode…) which have never been ported to kbd.
I doubt it's that rotten. It definitely works fine for the most popular keymaps, such as the american and german.
All this keymap stuff is bending my brain, but I've been poking at it for the last few days, and I'm rather afraid it *is* that bad. See this tentatively accepted blocker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=889562
If I have everything right, anaconda is offering a keymap list that it derives from xkb. I'm having trouble counting precisely how many layouts it offers, but it looks to be definitely over 400.
According to 'localectl list-keymaps', systemd-localed has mappings for 209 keymaps.
Well, that's simply a fact that the console keymaps are much fewer than the X keymaps, but that's not really an issue of localed/systemd, but rather a general shortcoming of the classic console keymap system. Also, it's hardly a regression in comparison to older Fedora...
So there's at least 191 keymaps (probably rather more) which anaconda offers you but which systemd doesn't understand: if you install with any of these keymaps selected as the default keymap (top of the list in Keyboard spoke), you will wind up with US as your console keyboard layout on the installed system.
We could really do with input from interested parties on exactly how bad of a problem this is - if people could look through the keyboard layouts offered in F18's Keyboard spoke and compare them to the list from 'localectl list-keymaps', and identify particularly important ones that systemd doesn't seem to grok, it'd really help.
"localectl list-keymaps" shows all files below /usr/lib/kbd/keymaps btw, that's all it does...
Lennart
Le Lun 24 décembre 2012 12:56, Lennart Poettering a écrit :
On Fri, 21.12.12 16:11, Adam Williamson (awilliam@redhat.com) wrote:
If I have everything right, anaconda is offering a keymap list that it derives from xkb. I'm having trouble counting precisely how many layouts it offers, but it looks to be definitely over 400.
According to 'localectl list-keymaps', systemd-localed has mappings for 209 keymaps.
Well, that's simply a fact that the console keymaps are much fewer than the X keymaps, but that's not really an issue of localed/systemd, but rather a general shortcoming of the classic console keymap system.
It's not a shortcoming of the classic console keymap system
It's a shortcoming of using a separate layout source for the console.
Writing layouts is *hard*. The syntax is unfriendly. You spend hours fool-proofing a design and then users ask you to move some symbols or Unicode.org finally standardises a symbol that your language needed before but that was not available and you need to rework the definition files without introducing new bugs.
Nobody is going to do this work twice if there is a way to avoid it (and if you try to do it twice you will introduce discrepancies users will complain about).
Debian/Ubuntu provided a way to avoid work duplication a long time ago. Ergo, no one is seriously working on the kbd database anymore. No amount of mapping lists is going to change that. 10 years of RH∕Fedora refusing to acknowledge this situation didn't bring layout authors back kbd-side. To get correct i18n layouts in kbd you need to source them from xkb-config one way or another or get someone to write all the missing kbd layout defs (and I posit he'll either go insane halfway through or do it through a script like debian because doing it manually is a Sisyphean task)
Please remember layouts were the only bit hairy enough Xfree86.org and X.org agreed to continue collaborating on them when they split.
Also, it's hardly a regression in comparison to older Fedora...
i18n has moved a long way since the 90's. Being stuck in the past may be not a regression but it's nothing to be proud of.
On Sun, 30.12.12 17:53, Nicolas Mailhot (nicolas.mailhot@laposte.net) wrote:
It's not a shortcoming of the classic console keymap system
It's a shortcoming of using a separate layout source for the console.
Cool, then write a sane tool that converts them online that doesn't pull in Perl and whatnot, or find a way to covnert all keymaps offline so that we can ship the pre-packaged and I'd be more than happy to integrate that nicely into systemd.
Everything else is just pointless repeating and whining.
Lennart
Cool, then write a sane tool that converts them online that doesn't pull in Perl and whatnot,
Is 'awk' available? 'sed'? 'bash'? (I'm not kidding. Some systems prefer 'dash', which lacks arrays and other hard-to-substitute features.) How much of 'python' is allowed? 'lua'? In other words, please specify the desired environment, with cost (penalty) functions near the boundary.
or find a way to convert all keymaps offline
There are "user" keymaps written in the classic console keymap system. Thus any offline conversion mechanism must be exported. In some cases the use may be online, so the cost curve still matters.
On Mon, 31.12.12 07:38, John Reiser (jreiser@bitwagon.com) wrote:
Cool, then write a sane tool that converts them online that doesn't pull in Perl and whatnot,
Is 'awk' available? 'sed'? 'bash'? (I'm not kidding. Some systems prefer 'dash', which lacks arrays and other hard-to-substitute features.) How much of 'python' is allowed? 'lua'? In other words, please specify the desired environment, with cost (penalty) functions near the boundary.
How about C?
Lennart
On Tue, Jan 1, 2013 at 1:03 AM, Lennart Poettering mzerqung@0pointer.de wrote:
On Mon, 31.12.12 07:38, John Reiser (jreiser@bitwagon.com) wrote:
Cool, then write a sane tool that converts them online that doesn't pull in Perl and whatnot,
Is 'awk' available? 'sed'? 'bash'? (I'm not kidding. Some systems prefer 'dash', which lacks arrays and other hard-to-substitute features.) How much of 'python' is allowed? 'lua'? In other words, please specify the desired environment, with cost (penalty) functions near the boundary.
How about C?
Which sets of libraries do we assume are installed?
Lennart
-- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 01.01.13 10:48, Joel Rees (joel.rees@gmail.com) wrote:
On Tue, Jan 1, 2013 at 1:03 AM, Lennart Poettering mzerqung@0pointer.de wrote:
On Mon, 31.12.12 07:38, John Reiser (jreiser@bitwagon.com) wrote:
Cool, then write a sane tool that converts them online that doesn't pull in Perl and whatnot,
Is 'awk' available? 'sed'? 'bash'? (I'm not kidding. Some systems prefer 'dash', which lacks arrays and other hard-to-substitute features.) How much of 'python' is allowed? 'lua'? In other words, please specify the desired environment, with cost (penalty) functions near the boundary.
How about C?
Which sets of libraries do we assume are installed?
glibc, glib, and similar low-level stuff.
Lennart
On Sun, 2012-12-30 at 17:53 +0100, Nicolas Mailhot wrote:
Also, it's hardly a regression in comparison to older Fedora...
i18n has moved a long way since the 90's. Being stuck in the past may be not a regression but it's nothing to be proud of.
In addition to this, though the number of console keymaps systemd understands may not be a regression, it is contributing to one.
All this is explained in the bug and in my earlier comment, but the problem is that anaconda in F18 is now simply offering the user the entire xkb list of keymaps. In F17 it offered some kind of hand-weeded (and fairly small) list of keymaps which was presumably then carefully supervised through later config steps: in F18, it just gives you the entire xkb list to choose from, and then uses systemd-localed to try and configure a corresponding console layout for whatever you pick.
As discussed in the bug, if systemd-localed is doing 'fuzzy matching' it may be the case that we actually get a decent match for most layouts, I'll have to do more testing. But the situation is clearly different to the F17 one in that we are now relying on systemd-localed to map xkb layouts to console ones, where we really weren't before. There is certainly at least a potential for regression here. The systemd-localed list of keymaps may not have regressed but it has taken on more significance.
On Mon, 2012-12-31 at 15:01 -0800, Adam Williamson wrote:
As discussed in the bug, if systemd-localed is doing 'fuzzy matching' it may be the case that we actually get a decent match for most layouts, I'll have to do more testing. But the situation is clearly different to the F17 one in that we are now relying on systemd-localed to map xkb layouts to console ones, where we really weren't before. There is certainly at least a potential for regression here. The systemd-localed list of keymaps may not have regressed but it has taken on more significance.
OK. Since that last mail I investigated things in quite a lot more detail.
The big takeaway from that: the gap between 'kbd' and 'xkb' coverage is just way too large for this 'mapping' solution to be practical going forward. We really need the code to support xkb layouts at the console, it is the only sane way forward. I have sent patches to systemd to improve the xkb<->kbd mapping a little bit, but there are just huge swathes of layouts xkb has which kbd simply does not have, and there's no way to patch around that. We simply need to ditch kbd and have One True Source Of Keymaps. This should be a high priority for F19 development. If I could write code, this is the code I would be writing.
On Fri, Jan 4, 2013 at 7:23 AM, Adam Williamson awilliam@redhat.com wrote:
On Mon, 2012-12-31 at 15:01 -0800, Adam Williamson wrote:
As discussed in the bug, if systemd-localed is doing 'fuzzy matching' it may be the case that we actually get a decent match for most layouts, I'll have to do more testing. But the situation is clearly different to the F17 one in that we are now relying on systemd-localed to map xkb layouts to console ones, where we really weren't before. There is certainly at least a potential for regression here. The systemd-localed list of keymaps may not have regressed but it has taken on more significance.
OK. Since that last mail I investigated things in quite a lot more detail.
The big takeaway from that: the gap between 'kbd' and 'xkb' coverage is just way too large for this 'mapping' solution to be practical going forward. We really need the code to support xkb layouts at the console, it is the only sane way forward. I have sent patches to systemd to improve the xkb<->kbd mapping a little bit, but there are just huge swathes of layouts xkb has which kbd simply does not have, and there's no way to patch around that. We simply need to ditch kbd and have One True Source Of Keymaps. This should be a high priority for F19 development. If I could write code, this is the code I would be writing.
Either way, this is the kind of code I used to enjoy writing, back in another life. Too bad I have to work at something else these days to pay rent and feed the wife and kids.
But, knowing first hand about how many different keyboard layouts, controllers, manufacturers, sources of the maps and other documentation, etc., there are, I'd agree with your conclusion that it's a lot of work to go to for not much gain, to duplicate the xkb keymaps for kbd. I'm definitely guessing that all the strange irregular details make automated conversion a really hard problem.
Setting up different automatic conversion programs for different classes of keyboards might be a good approach (and a good job for long-term job security if someone were paying for it). But I think it would not be particularly timely, relative to coming releases of Fedora.
-- Joel Rees
On Mon, Dec 03, 2012 at 09:20:05AM +0200, Panu Matilainen wrote:
On 12/02/2012 10:57 PM, Miloslav Trmač wrote:
On Sun, Dec 2, 2012 at 12:38 AM, Sérgio Basto sergio@serjux.com wrote:
system-config-keyboard should do this:
1. Get the old settings: cat /etc/sysconfig/keyboard 2. Set the new settings: su -c 'localectl set-x11-keymap <layout> [<model>] [<variant>] [<options>]' 3. Remove the old configuration file: su -c 'rm /etc/sysconfig/keyboard'or at least warning that we should do something new like this .
http://pkgs.fedoraproject.org/cgit/systemd.git/commit/?h=f18&id=0969ad24... already attempts to do some kind of automatic conversion. If that is insufficient, please file bugs against systemd.
It seems that the virtual console layout is migrated ok, but the x11 part is not. This is what I get on my two upgraded F18 boxes:
[root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: n/a [root@turre ~]#
The "n/a" part is the "problem" as it falls back to US keyboard. localectl manual says both set-keymap and set-x11-keymap apply to both the keymaps unless --no-convert is specified, but that doesn't seem to happen in practise:
[root@turre ~]# localectl set-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: n/a [root@turre ~]# localectl set-x11-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi-latin1 X11 Layout: fi [root@turre ~]# localectl set-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: fi X11 Model: pc105 X11 Options: terminate:ctrl_alt_bksp
It's a bit bizarre: set-keymap doesn't seem to find "fi" as the closest matching keyboard for x11 (it probably should), set-x11-keymap considers "fi-latin1" to be the closest matching keymap for "fi", but in this specific order its possible to get both set to "fi". Only it now adds additional model + options there, whatever the reason.
pc105 is just the standard model that XKB uses. and the option is there to get zapping behaviour when the server is started (until that option is overwritten by a desktop environment or other client)
Cheers, Peter
On 12/04/2012 04:59 AM, Peter Hutterer wrote:
On Mon, Dec 03, 2012 at 09:20:05AM +0200, Panu Matilainen wrote:
On 12/02/2012 10:57 PM, Miloslav Trmač wrote:
On Sun, Dec 2, 2012 at 12:38 AM, Sérgio Basto sergio@serjux.com wrote:
system-config-keyboard should do this:
1. Get the old settings: cat /etc/sysconfig/keyboard 2. Set the new settings: su -c 'localectl set-x11-keymap <layout> [<model>] [<variant>] [<options>]' 3. Remove the old configuration file: su -c 'rm /etc/sysconfig/keyboard'or at least warning that we should do something new like this .
http://pkgs.fedoraproject.org/cgit/systemd.git/commit/?h=f18&id=0969ad24... already attempts to do some kind of automatic conversion. If that is insufficient, please file bugs against systemd.
It seems that the virtual console layout is migrated ok, but the x11 part is not. This is what I get on my two upgraded F18 boxes:
[root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: n/a [root@turre ~]#
The "n/a" part is the "problem" as it falls back to US keyboard. localectl manual says both set-keymap and set-x11-keymap apply to both the keymaps unless --no-convert is specified, but that doesn't seem to happen in practise:
[root@turre ~]# localectl set-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: n/a [root@turre ~]# localectl set-x11-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi-latin1 X11 Layout: fi [root@turre ~]# localectl set-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: fi X11 Model: pc105 X11 Options: terminate:ctrl_alt_bksp
It's a bit bizarre: set-keymap doesn't seem to find "fi" as the closest matching keyboard for x11 (it probably should), set-x11-keymap considers "fi-latin1" to be the closest matching keymap for "fi", but in this specific order its possible to get both set to "fi". Only it now adds additional model + options there, whatever the reason.
pc105 is just the standard model that XKB uses. and the option is there to get zapping behaviour when the server is started (until that option is overwritten by a desktop environment or other client)
Sure. The point is that if those options are needed, why are they only appearing after setting the VC keymap when X11 keymap has been already set, but not when the X11 keymap is first set? And why does setting VC keymap change such things for the X11 keymap? This just looks fairly bizarre on the whole.
- Panu -
On 30 November 2012 12:33, Jan Včelák jvcelak@redhat.com wrote:
If 'localectl' is the only supported way, we should add this information to "Upgrading Fedora using yum" instructions on the wiki. The same with old kernel options. (I do not know how is this handled in the other upgrade methods.)
If the old configuration files are supposed to work, what is the responsible component I should file bug on?
For what it's worth, I just upgraded with "fedup" and my keyboard went from UK English to US English. Just used system-config-keyboard to change it and that seemed to work ...
MEF
On Friday 30 of November 2012 14:15:11, Mary Ellen Foster wrote:
For what it's worth, I just upgraded with "fedup" and my keyboard went from UK English to US English. Just used system-config-keyboard to change it and that seemed to work ...
I tried that and the change was not persistent. At least with kdm + KDE.
Jan
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Bill Nottingham -
Jan Vcelak -
Joel Rees -
John Reiser -
Lennart Poettering -
Marcela Mašláňová -
Mary Ellen Foster -
Miloslav Trmač -
Nicolas Mailhot -
Oron Peled -
Panu Matilainen -
Peter Hutterer -
Rahul Sundaram -
Ray Strode -
Sérgio Basto -
Vratislav Podzimek