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): How reproducible: Always 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. Additional info:
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: http://bugs.kde.org/show_bug.cgi?id=80970
Thanks Mary, 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 solution. 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 comment #5)
The bug has resurfaced in the kde-3.3.1 build on ftp.kde.org.
Direct link to patch from bugs.kde.org: http://bugs.kde.org/attachment.cgi?id=7725&action=view
This bug seems to have resurfaced in FC5test1. I opened a new bug (although maybe I should have just reopened this one ...) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174553