Red Hat Bugzilla – Bug 121950
where are the KDE keyboard layouts?
Last modified: 2007-11-30 17:10:41 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Description of problem:
I wanted to switch my keyboard layout in KDE to dvorak, but when I went to make the change in the control centre (Regional & Accessibility - Keyboard Layout), there were no layouts to choose from.
Did I need to install a specific package to have the layouts available? As far as I can recall, I installed my normal assortment of packages (all of KDE, pluse kde-i18n-en_GB).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open the control centre and try to choose a new keyboard layout
Actual Results: There are no layouts to choose from.
Expected Results: Normally there's a whole list of layouts there.
We have the same problem here. I suspect that it's not a kde problem
but an X.org problem.
I hope that this gets corrected before the final FC2 release...
yes, it's a xorg-x11 problem. The file name of rules were renamed to xorg!
so KDE Keyboard_layout does not find them. To fix this problem, it's
needed to add some symlinks in /usr/X11R6/lib/X11/xkb/rules
ln -s xorg-it.lst xfree86-it.lst
ln -s xorg.lst xfree86.lst
ln -s xorg.xml xfree86.xml
Mike, could you please add the symlinks in next xorg rebuild. Thanks
Beautiful! Adding those links worked 100% for me.
This is not an xorg-x11 bug. This is a bug in the application/lib
that is hard coding the name of the xkb rules file to be "xfree86".
Also, just changing an app/lib to use "xorg" as the xkbrules name
is also incorrect, because it then makes the app/lib hard coded to
only work with X.org X11, and wont work with XFree86 anymore.
The proper way to do this is to query the X server for the xkb rules
name using XKB APIs, like setxkbmap does. Make sure your X server
config file does not hard code the xkbrules option also, or it will
break things. Fixing broken applications/libraries to do this
properly is very important, because the xkbrules file is going to
be split out into a separate package "xkbdesc" during the
modularization effort, and be renamed upstream again very soon to
be X11 implementation neutral. The current name they're planning
on using is "base", so every app that brokenly hard codes "xfree86"
or "xorg" will break again when it's renamed to "base".
Please fix your applications/libraries to use the XKB API and
query the server for the xkbrules default. "setxkbmap" source
code can be used as an example if these APIs are unfamiliar.
Hope this helps.
I just bugzilla'd this at kde:
XkbRF_GetNamesProp() is the API function that should provide this
information. The KDE developers can use that to replace the hard
coded method used currently and it should provide a more robust
Hope this helps!
Mike, i agree that the applications should not hard code the name of
the xkb rules file. it should be fixed.
it looks like the setxkbmap is still using "xfree86" as default rule :(
running "setxkbmap -model pc104 -layout us -variant basic", i got errors:
Couldn't find rules file (xfree86)
The kde keyboard layout just uses setxkbmap to set keyboard layout.
I think setxkbmap should be fixed.
Than: I have investigated setxkbmap personally, and single stepped
through it's code a couple of weeks ago. The setxkbmap code works
properly, and queries the X server for the xkbrules and other
information. The only way it will return "xfree86" is if the
X server config file has hard coded the override:
Option "xkbrules" "xfree86"
If the X server config file contains the above line, then setxkbmap
is doing the correct thing by returning "xfree86" because the
X server is misconfigured. In this case, it is not a bug in
setxkbmap, and not a bug in the X server. It is a misconfigured
X server. The proper solution in this case, is to reconfigure the
X server properly to not hard code the above override which is
XFree86 specific, because it will not work with X.org X11.
For additional details, see bug alias "xkbrules-setxkbmap", which
explains the problem a bit further. There is no bug in setxkbmap.
Hope this helps.
I believe this bug is a duplicate of bug #121016 (xkbrules-setxkbmap),
in which case the fix, is to edit the X server config file (xorg.conf)
and remove the line:
Option "xkbrules" "xfree86"
Once this line is removed, restart the X server, then review the
X server log file where it will indicate what config file is being
used (should be xorg.conf, make sure it shows this). Running
setxkbmap should now work properly. As indicated above, when I
single-step through the setxkbmap code with a properly configured
X server, it correctly indicates that "xorg" is the XkbRules file,
without hard coding anything.
that it is u
Mike, man thanks for your infos.
*** Bug 122656 has been marked as a duplicate of this bug. ***
I doubt that the KDE people will get this problem fixed for the final
release of FC2.
Will the Fedora developers be correcting the problem with the symbolic
links suggested by comment #2 (Ngo Than)?
I've had the problem with KDE keyboard layouts that are now solved
with adding the symbolic links mentionned (thank you). My xorg.conf
never had the 'Option' mentionned above.
i have added a patch in kdebase, which should fix this problem.
the kdebase-3.2.2-6 should have this fix. it will show up in rawhide
soon. Thanks for your report.
Why not released with FC2 ?
*** Bug 124238 has been marked as a duplicate of this bug. ***
kdebase-3.2.2-6 is nowhere to be found anymore.
kdebase-3.2.3-1 from Fedora development is incompatible with FC2.
kdebase-3.2.3-0.1 from ftp.kde.org is suspecious because kdepim is 6x
the normal size there.
Please issue an official update that would finally enable i18nizing.
There is no need to wait for a better reason
i will do official update for FC2 soon.
FYI, I posted a patch updated for kde-3.3.x on bugs.kde.org (see
The bug has resurfaced in the kde-3.3.1 build on ftp.kde.org.
Direct link to patch from bugs.kde.org:
This bug seems to have resurfaced in FC5test1. I opened a new bug (although
maybe I should have just reopened this one ...)