Weird problem with uk layout locking x server

[Duncan]

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.