On Fri, Jan 4, 2013 at 7:23 AM, Adam Williamson <awilliam@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
