Edgar Kalkowski posted on Fri, 11 Sep 2009 23:40:41 +0200 as excerpted:
> The only problem I have is when trying to set the keyboard layout to the> UK one from within the KDE systemsettings (keyboard driver is evdev). If> I do this my X eats up 100 % CPU every time I switch to a terminal login> (Ctrl+Alt+F1 for example) and back to my KDE session. To elaborate: I> change the keyboard layout to UK and switch to a terminal login via> Ctrl+Alt+F1. I then switch back to KDE with Ctrl+Alt+F7 and end up with> an almost completely locked up system as X is up to 100 % CPU load.> > I normally do not use the terminal logins but as the system apparently> also switches to a terminal when suspending and resuming this is kind of> annoying. ;)> > A workaround that works for me is to leave the KDE keyboard layout> setting untouched and put “setxkbmap gb; xmodmap ~/.Xmodmap” in a KDE> autostart script.
I don't really do i18n stuff, so can't really help you with that end nor can I confirm the issue (perhaps someone else here can), but...
What it sounds like what might be happening is that you end up with two parts, one X and one KDE, with hal probably thrown in there on one side or the other as well, and maybe qt4 too, fighting each other, perhaps setting and resetting the keyboard.
You've already mentioned a working workaround, using ~/.Xmodmap, so it sounds like you have things under control, and I *CAN* add that as of 4.3.1, kde4 DOES still have a number of serious bugs and missing features where I myself have had to come up with various workarounds, so the scenario isn't unfamiliar to me at all, even if I don't need to worry about this specific one.
The issue that most parallels it for me is that I have two monitors, and can't touch KDE's kcontrol/system-settings display applet, or things go all crazy on me, too. As you've done with X's own ~/.Xmodmap for keyboard settings, so I've done with xorg.conf, setting it up initially the way I want, and using scripted xrandr calls to change resolutions when I need to, thus avoiding the kcontrol display applet "everything goes screwy" issue. 4.3.1 is DEFINITELY better than 4.3.0 (which was WORSE than 4.2.4), as with 4.3.0, I couldn't even switch to that applet at all,say by clicking it accidently, without everything going screwy, without even as much as having time to see the contexts let alone touching anything. 4.3.1 is more or less back to 4.2.4 level. I can click on the applet and look around in it, but I dare not actually twiddle anything or things go haywire. But it's not X itself, as xrandr works just fine.
Actually, in my case, it's a known issue, as I've seen reports on it I think on the lists, and bug reports. The problem seems to be that for whatever reason, the applet doesn't sense the second CRTC or something, and thus sees two monitors but displays them as working off the same CRTC and thus can only set them into clone mode. I have the controls for each monitor, resolution, orientation, etc, but am missing the critical POSITION control. I didn't even know that until I came across that other report, where one guy posted a screenshot of the applet as I see it, controls for both monitors but without the position selector, and someone else then posted it as he had it and how it's /supposed/ to show up, with the position control that would let the operator select clone mode, above, below, to the right or left of, etc, exactly the same sort of functionality that xrandr has, but that the kcontrol display applet (and krandrtray) is missing for me and that other guy whose report I was reading. I've heard rumors that the bug is fixed in the 4.4 branch, but of course it'll be January or so before that comes out, and I'm guessing late November before the betas and rcs start hitting, if I don't want to run live-SVN/GIT versions, and I don't at this point.
Back to the keyboard thing. I mentioned hal, which is responsible in most modern distributions for doing the input hotplugging. It can be configured to handle the layout and etc too, tho it's nowhere near as easy as setting it with kde would be if it worked. While I only use standard en-US locale, layout, etc, so didn't have that problem, I DO have one of those media keyboards with lots of extra keys, and when I upgraded from the old X that handled it via xorg.conf to the new one that normally handles it via evdev and hal, I learned how to configure hal for my setup, to enable all those extra keys. If you'd like, I can probably guide you thru doing the same, or at least to the documentation. It's not /too/ hard once you understand what's happening. My biggest issue was that the documentation I was following (early draft Gentoo documentation, with referrals to various X docs, blogs, etc.) didn't mention a kernel module that I needed, and I spent several hours futilely trying to trace down why X and hal wasn't working as it should, when I didn't even have the driver I needed! Once I groked that and recompiled my (custom compiled) kernel with the correct driver, it was relatively easy. You already have that or it'd not be working with the X ~/.Xmodmap settings, so it shouldn't be too bad.
Never-the-less, that wouldn't get kde working, it'd just setup X to deal with it automatically, which is more or less what you're already doing using ~/.Xmodemap, so I really don't see an particular benefit in messing with what's working reasonably well already. But you might and I'm willing to work with you if you want to do it. It's up to you.
-- Duncan - List replies preferred. No HTML msgs."Every nonfree program has a lord, a master --and if you use the program, he is your master." Richard Stallman
___________________________________________________This message is from the kde mailing list.Account management: https://mail.kde.org/mailman/listinfo/kde.Archives: http://lists.kde.org/.More info: http://www.kde.org/faq.html.
