Dmt Ops posted on Thu, 21 Mar 2013 21:45:02 -0700 as excerpted:
> I'm key mapping a custom keyboard in KED
I wasn't familiar with KED, so googled it. Google suggests "KDE", so
given the list, I'll assume you meant that.
(I DID learn what a "KED" was in EMT/emergency-medical-tech terms, tho.
Assuming you don't know either, try entering "ked" on wikipedia and/or
youtube (the wikipedia diagram wasn't particularly helpful, but the
youtube videos make it clear! FWIW I used minitube here, as I don't run
the proprietary flash plugin and thus youtube doesn't play in my browser,
but minitube handles it =:^) and learn as I just did. "Kendrick
Extraction Device", to help extract victims from car accidents, etc,
where there may be neck or spine injury, while minimizing the chance of
additional injury including possible paralysis due to that spine injury.
I hadn't the foggiest before you prompted my search, so thanks! =:^)
> on:
>
> lsb_release -rd
> Description: openSUSE 12.3 (x86_64)
> Release: 12.3
>
> kde4-config -version
> Qt: 4.8.4 KDE Development Platform: 4.10.1 "release 545"
> kde4-config: 1.0
Thanks for including that information. Way too many people don't include
their kde version, and for people on other distributions that don't have
a clue what kde shipped with that particular distro release...
Meanwhile, a request, before we get into the issue at hand...
Please post in plain text, not HTML, on the list. Some people prefer to
use clients that don't parse the HTML for security or other reasons, and
the raw HTML isn't very pretty to look at. I know I'm not the only one
that believes if it takes HTML to make it worth reading, it's NOT worth
reading. (FWIW, your post included both HTML and plain text.)
Fortunately, most folks are happy to switch to plain-text-only when
asked. After all, it doesn't pay to irritate the people that could have
your answer. =:^)
Now to the issue at hand...
> I want to map a multi-key chord ("fn"+"F12") in KDE to "eject" my DVD
> drive.
>
> The keys are active
>
> @ xev
>
> press "F12"
> KeyRelease event, serial 40, synthetic NO, window 0x3a00001,
> root 0x264, subw 0x0, time 2099398, (426,527),
> root:(430,591), state 0x10, keycode 96
> (keysym 0xffc9, F12), same_screen YES,
> XLookupString gives 0 bytes:
> XFilterEvent returns: False
>
>
> press "fn"
> KeyPress event, serial 40, synthetic NO, window 0x3a00001,
> root 0x264, subw 0x0, time 2103556, (426,527),
> root:(430,591), state 0x10, keycode 135
> (keysym 0xffe8, Meta_R), same_screen YES,
> XLookupString gives 0 bytes:
> XmbLookupString gives 0 bytes:
> XFilterEvent returns: False
Cool! I routinely use xev for key diagnostics too. =:^)
FWIW I had no idea what "fn" was, especially in a context where it was
clearly not the function keys F1-F12, but Meta_R... THAT I understand
(well, to some degree).
> The keysym for eject is defined
>
> grep -i eject /usr/include/X11/XF86keysym.h
> #define XF86XK_Eject 0x1008FF2C /* Eject device (e.g. DVD) */
>
> 1st mod'ing a single-key solution,
>
> edit ~/.Xmodmap
> - keycode 96 = F12 F12 F12 F12 F12 F12 XF86Switch_VT_12
> + keycode 96 = XF86XK_Eject F12 F12 F12 F12 F12 XF86Switch_VT_12
>
> then
>
> xmodmap ~/.Xmodmap
>
> returns
>
> xmodmap ~/.Xmodmap
> xmodmap: /home/user/.Xmodmap:89:
> bad keysym name 'XF86XK_Eject' in keysym list
> xmodmap: 1 error encountered, aborting.
>
> otoh, mod'ing again
>
> edit ~/.Xmodmap
> - keycode 96 = XF86XK_Eject F12 F12 F12 F12 F12 XF86Switch_VT_12
> + keycode 96 = XF86Eject F12 F12 F12 F12 F12 XF86Switch_VT_12
>
> now
>
> xmodmap ~/.Xmodmap
>
> succeeds
>
> @ xev
>
> KeyPress event, serial 40, synthetic NO, window 0x3600001,
> root 0x264, subw 0x0, time 2922751, (596,464),
> root:(600,528), state 0x10, keycode 96
> (keysym 0x1008ff2c, XF86Eject), same_screen YES,
> XLookupString gives 0 bytes:
> XmbLookupString gives 0 bytes:
> XFilterEvent returns: False
>
> (1) Should not .Xmodmap not use the "XF86XK_Eject" keysym defined in
>
> /usr/include/X11/XF86keysym.h
>
> instead of requiring
>
> "XF86Eject"
>
> or does the keycode definition NOT use the keysym ?
I've never used xmodmap so I can't answer that question definitively.
However, my keyboard (a logitech cordless desktop pro) does have a number
of "extra" keys, which xev normally reports as XF86Home, XF86AudioPlay,
etc. And those keynames (without any XK_) are what khotkeys uses as
well. So an educated guess is that the XK_ is a stripped prefix, leaving
only XF86Eject.
But...
> (2) In any case, what next steps do I need to take to 1st get a single-,
> then two-, key-press to actually eject the drive drawer? So far, I've
> not managed with any keystroke to actually get the drive to
> eject.
I believe you're conflating two separate things here, the NAME of the key
(XF86Eject, as you've mapped it, apparently a meta-modified F12,
otherwise), with the FUNCTION the key triggers (media ejection). You
simply changed the name of the key, but that's just the name, it has to
map to a function, and something has to do that mapping. KDE does have
default mappings for some more common keys including XF86Audio*
(RaiseVolume, LowerVolume, Mute, etc), but XF86Eject is apparently not
common enough to get a default mapping. (Or maybe enough people have two
or more removable media devices, a few years ago it would have been a CD
burner and a DVD player, these days it'd be a DVD burner and a Bluray
player), that the kde folks were afraid they'd choose the wrong one to
eject, so they left that undefined.)
Here's where khotkeys steps in. Or rather, there's three related kde
hotkeys (and configurations) that affect hotkeys/shortcuts in kde4,
khotkeys (aka custom shortcuts) being the one of interest here, with at
least three different configuration methods available to configure what
you want.
The first thing you need to do is find a command (very likely CLI,
command-line interface, not GUI) that does what you need. Once you have
an appropriate command, you can setup a kde hotkey that triggers it, just
as you can setup a hotkey to trigger any other command.
Assuming you don't have a different preference, see if you have an
"eject" command. Very likely you will, as it's part of the util-linux
package which includes such basics as mount, dmesg, fsck, etc, so it's
pretty standard for Linux installations.
Now run "eject" from the commandline and see if it does what you'd
expect. (Note that additionally, depending on the device, it can often
be used to close an open tray, as well as eject/open a closed tray.) If
it does, you have a good command. If that doesn't work, you may need to
add the device name or other options as appropriate. You will likely
find the eject (1) manpage useful in this case.
Once you have a command that works from the command line, you need to map
a kde hotkey to it. As mentioned above, there's at least three ways to
do this. Two of them are found in "the application formerly known as
kcontrol"[1], under common appearance and behavior, shortcuts and
gestures, custom shortcuts. Or run kcmshell4 khotkeys to get the same
module by itself.[2]
Note that khotkeys allows configuration of mouse-gesture triggers as well
as keyboard shortcuts, and that you can choose to have them be available
from only a single app, or globally, which I guess you'd want. I'll omit
the specific steps here as I expect that if you can figure out xmodmap,
you can figure this out from here, but if you get stuck, holler for the
step-by-step.
You should be able to assign either the default Meta-F12, or the xmodmap-
modified XF86Eject, depending on how that key is actually defined when
you set it up in khotkeys. Take your pick.
One additional note about khotkeys: In kde3 it was possible to setup
multikey triggers (say XF86Eject, 1, to eject your cdburner, XF86Eject,
2, to eject your bluray player), thus effectively allowing you to have
the first key act as a menu-launcher for all the actions defined as a
combo of it and a second key (in the example above, hitting XF86Eject
would popup a submenu with two entries, 1 and 2).[3] In kde4, that's not
possible, except that standard X modified keys count separately from
their unmodified variant, so Shift-XF86Eject, Alt-XF86Eject, Alt-Shift-
XF86Eject, and plain unmodified XF86Eject, all are separately defined
hotkeys. (At least that's the way it normally works when there's a
separate XF86Eject key, or in my case XF86Home, etc. With your
definition of Meta-F12 as XF86Eject, I'm not sure if it'll still be
XF86Eject with the other modifiers applied or not. But it should be
either that or the modifiers F12. Either way it'd be the same key, just
different names for it.) But say XF86Eject, 1, won't map. It'll take
the XF86Eject, without a way to add the second sequential key, the 1, to
it.
There has been a bug filed against that multi-key regression from kde3
since early kde4, and at least at one point around kde 4.3, it on the
most-popular-bugs list, but based on a comment from one of the devs, qt4
simply didn't have the required functionality available to map, as
apparently qt3 did, and nobody raw-coded it in kde apart from qt, so...
In a different context, however, I read that the required functionality
went into qt5 well before even the qt5 betas, or at least that's the way
I interpreted what I read, so with kde frameworks aka kde5, hopefully
that functionality will reappear.
But your choice of Meta-F12 (or equivalently if you keep the xmodmap
setting, XF86Eject) should work, since that's seen as a single X-modified
key, not two separate keys.
The other two ways of configuring a solution involve another step. Use
kmenuedit to create a menu entry (or create the *.desktop file manually
yourself, if you're familiar enough with the format to do so) for the
command, setting an icon, etc, just as you would for any other custom
menu entry you might create.
With that done and the entry in kde's menu, you can set a hotkey for the
menu entry, again, just as you would for any other menu entry. This can
be done in kmenuedit as well, or you can use khotkeys (aka Custom
shortcuts, the kcontrol applet mentioned above) to setup or manage the
entry. Personally, I've found that kmenuedit works well for the initial
setup, but that after you've setup a few, managing them can be easier in
khotkeys, since you're managing ONLY the hotkeys there, whereas in
kmenuedit, you're managing the whole applications menu.
But as I said above, if all you're doing is setting up a shortcut for a
command you'd otherwise enter at the command prompt, doing it directly
via khotkeys is the easiest method.
---
[1] "The application formerly known as kcontrol": That description takes
a hint from the description from "the artist formerly known as Prince".
kcontrol was the kde3 name. It's called system settings in kde4, altho
by and large they're user-specific kde-specific settings having little or
nothing to do with the global system settings that the "system setting"
name suggests, or even with, say, CLI apps, run by the same user! The
time can be set for the system there, and there's a few other similarly
global settings, but for the most part it's kde specific settings for
that specific user, and kcontrol thus remains by far the most accurate
name. Meanwhile, despite the inaccurate user-facing name, the modules
themselves are still "kcm's", kcontrol-modules, and in ordered to run
just one of them, you still run kcmshell4. And last I checked (kde 4.5
or so), kde's bugzilla still used the kcontrol name for that module, as
well.
[2] The kcmshell4 subcommands for the other two applets under shortcuts
and gestures are keys, which brings up the global shortcut dialog, where
global hotkeys for kwin, plasma, kmix, etc, are configured, and
standard_actions, which configures the default kde-standard hotkeys used
across multiple kde apps, like cut/copy/paste, undo/redo, print, prefs
dialog, etc. But it's khotkeys that we're interested in here.
[3] Thus, I had a whole stack of hotkeys assigned to a combination of
XF86Home and a letter key, or a number key, or... with the XF86Home key
thus acting as a launcher menu key. In my head, then, instead of
XF86Home, I'd say, Launch, and they sequence would be for example,
Launch, B, to launch the web Browser, Launch, P, to launch kpatience,
Launch, F, to launch the file manager (konqueror in file-management mode
back then, now it'd be dolphin by default), Launch, T, for a terminal
window (konsole), etc.
As a result of this regression I had a /terrible/ time migrating to kde4,
since all my stacked hotkeys, and the "muscle memory" behind them, no
longer worked! So I started looking for a generic alternative. I did
eventually find one that would have worked, xbindkeys, but only in
advanced mode, which used a form of scheme script to allow all sorts of
interesting things. (In addition to multi-keys hit sequentially, which is
what I was after, you could setup a short keypress to do one thing, while
a long one did another, or setup arbitrary modifiers that all had to be
hit at the same time, like X-based modifiers except you could make any
key the modifier, etc.) But I didn't know scheme, and despite kde's very
public promise of support for kde3 as long as it had users, kde had
DROPPED support for kde3 and gentoo was going to be dropping support a
few months later as a result, so I needed a workable kde4 solution for
this and a whole list of other things reasonably quickly, and I really
had no time to learn a new scripting language to do it!
Fortunately, while playing around with xbindkeys I had an epiphany.
Instead of a single app having to handle the whole sequence of hotkeys I
wanted to use at once, I could handle them one at a time, having the
first hotkey launch an app that grabbed the second, which could if
necessary be an app that grabbed the third, etc.
And I DID know bash! So I set myself the task of hacking up a bash
script to handle things instead of having to learn scheme. What I ended
up with was a recursively called script. I have khotkeys setup with a
single hotkey (the familiar XF86Home), which opens a konsole window with
a script that takes exactly one key. Because I'm handling it with a bash
script in a konsole window, I don't have quite the flexibility that
khotkeys3 gave me, only the unmodified key, the shifted key, and the
control-key version. And some of the control-keys are off limits (^M and
^J, for instance, carriage-return and line-feed. So instead of the two-
key-sequence approach I used in kde3, I use a three-key-sequence, with
XF86Home popping up the script with a categories menu loaded (games, net,
config, terms, media, etc, hotkeys g, n, c, t, m, respectively), with
each category hotkey in turn recursively loading the same script, with
that category's menu. So for instance the media category menu looks like
this (mt is a scripted shortcut to mount, with my dedicated media and
news/nntp partitions, configured to be mountable by my ordinary user,
available for mount or umount, mpc is the music player client, a CLI
controller for mpd, the music player daemon, I mentioned minitube, the
youtube player, above, it's worth noting that on a US keyboard <> are the
shifted ,. keys, so those four are shifted and unshifted versions of the
same two keys, right next to each other):
#key description command
#### ########### ###############################
< player-prev mpc prev
, player-play mpc play
> player-next mpc next
. player-stop mpc stop
m m.media mt m m
M u.media mt m u
n m.news mt n m
N u.news mt n u
u minitube minitube
Enter key from first column.
Auto-cancel in 30 sec.:
Thus, using XF86Home as my launch key, configured thru khotkeys to launch
the script with the initial categories menu:
Launch m . ... (m=media) stops the media player.
Launch m u ... launches minitube.
Meanwhile...
Launch n b ... (net, bank) launches my browser with my bank login.
Launch g p ... (games, kpat) launches kpat... patience/solitaire
Launch g P ... (games, palapeli) launches palapeli, kde's jigsaw puzzler
Launch t t ... (terminals, normal-terminal) a normal konsole window
Launch t z ... (terminals, z) konsole, sudoing to my admin user (z)
It works reasonably well, tho there's a bit more latency than I'd like
since it IS a bash script, so I have to be careful not to hit the
sequence keys too fast, or it sits on the second menu waiting for a key
as I hit the second key before the menu launched.
--
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.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
