Re: [kde-linux] key board
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Date: Tue, 27 Jul 2010 23:49:52 +0000 (UTC)
Hans Krueger posted on Tue, 27 Jul 2010 09:40:50 -0400 as excerpted:
does anybody know what keyboard lay out I should use with suse 11.3 kde
4.4.4 I think for my acer travelmate 2480-2968 ? I'm have problems with
the delete,right,down key how do we set the win key to the aps menu
There's an X troubleshooting applet called xev that can help figure out
what the key association is, at least. If you run it from a konsole
window, it'll popup a little white window with a black-outlined square
inside. When the mouse is over the window (or dragging from it) you get
mouse events. As long as it is focused, you get keyboard events. These
events are listed to STDOUT, which if you've run it as I said from konsole,
will be the konsole window.
That won't help get the right keys mapped, but it'll help you figure out
what /is/ actually mapped.
I've never dealt with the kde keyboard i18n, but I know a bit about
setting the keyboard mapping config for X. There's three types of
keyboard setup, depending on how old an xorg-server you're running. (FWIW,
I don't know what X associates with what version of SuSE, I run Gentoo,
which lets the machine admin choose between multiple available versions.)
The old way setup the keyboard config in an InputDevice section of
xorg.conf. The config itself was straightforward, but knowing what
specific options to use sometimes wasn't. The middle way used hal
hotplugging. That was quite complex as it involved editing XML based hal
The newest way, from xorg-server 1.8 I believe, is very similar to the old
way. (hal is deprecated and its use phased out. Good riddance IMO, when
its hotplug just worked, great, but fixing things when it didn't was
terrible!) The format is generally the same, but there's additional
flexibility in that X's configuration can now live in multiple files in
xorg.conf.d instead of in a single xorg.conf, and a new InputClass section
that works for hotplugging but is FAR easier than hal to configure when
the hotplugging doesn't come up quite right, automatically.
Chances are you're either using the hal hotplug config method, or,
hopefully, the new xorg.conf.d InputClass method, as the old method really
is old now. If you let me know a bit more about the xorg-server version
you're running, and whether you have, probably, an /etc/X11/xorg.conf, or
an xorg.conf.d directory with multiple files in it, in the same location
(or both, the new way allows an xorg.conf file as well, for backward
compatibility), then I can help you with the config for either.
Regardless, however, getting the correct combo of core i18n keymapping and
extensions (like meta/win/super keys, plus the "extra" keys like the media
and inet keys that many modern keyboards have) so everything's mapped as
desired can be a bit complex, as X's keyboard config involves three levels
of mapping between keysyms, keys, etc.
But once you get the basics setup, then back in KDE, mapping specific keys
(such as the meta aka super aka win aka home aka linux key) to functions
such as launching the kickoff menu, isn't difficult at all. It's just
that if you're having trouble with more basic stuff like the delete,
right, and down-arrow keys, once you get your X mapping setup to handle
that, it may change what the meta/super/win/lin/home key produces, thereby
invalidating your previous kde mapping for it so you have to redo it.
Never-the-less, as I said, that bit's fairly easy to do and redo, so I
might as well mention it here. Once you know that the key is actually
producing something recognizable as a key event by X (using xev as above
to figure that out), simply right-click on whatever plasmoid widget
(including the kickoff, classic, or lancelot menu plasmoid, for that's all
they are, plasmoid widgets, just like others on the plasma desktop and
panels), and select the widget's settings (in this case, probably
application launcher settings). The dialog that pops up should be the
familiar kde config type with section icons to the left and settings for
the active section on the right. On the left, select Keyboard Shortcut,
then make the setting on the right.
Simple enough, with the one caveat being that in many configs, the lin/win/
meta key is a modifier like shift, alt, or control, and modifiers aren't
recognized as individual trigger keys on their own, they combine with
something to form a trigger.
But you can use something simple like meta-space for your menu launcher,
and the bonus is, that frees up other meta-key combos for use as other
(FWIW, keeping the general "win" key designation, I map various meta-key
combos to window-maximize (meta-pgup aka win-pgup), window-minimize (win-
pgdn), window-close (win-end, altered from the usual alt-F4), etc. Also,
I map win-h to the hide/show window border toggle, win-s to suspend/
unsuspend window compositing effects, win-ctrl-s to the snow effect, win-c
to the cube desktop switcher, etc. Or you can map them to launch specific
favorite apps, but I have extra keys on my keyboard and a custom script
setup for that, so one of the extra keys acts more like another modifier,
allowing me to stack multiple launchers on a single extra key, much as
multiple functions can be stacked on the win/meta/lin/home/super key when
it's registered as a modifier.)
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-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.
- [kde-linux] key board
- From: Hans Krueger
- [kde-linux] key board
- Prev by Date: [kde-linux] key board
- Next by Date: [kde] OpenGL window effect mislabeling
- Previous by thread: [kde-linux] key board
- Next by thread: [kde] OpenGL window effect mislabeling