Web lists-archives.com

Re: [kde-linux] can't get XF86XKEject xmodmap'd and working in/with KDE




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.