As L18L has correctly advised, jwm has precedence over ROX-Filer when grabbing a keypress event. So, as explained in L18L's post, you should first ensure that you have no lines beginning with
<Key keycode="111"> or
<Key key="Print"> in your jwmrc-personal, or any of your other jwmrc* or .jwmrc* configuration files.
If you find such lines, restart jwm after removing them. But if those files are OK and you still have the problem, read on - - -
Please try this test to see if the solution that worked for me will also work for you.
In a terminal window, run this command and then press
Print Screen:
You should see lots of output on your terminal window, including these two lines:
Code: Select all
state 0x0, keycode 111 (keysym 0xff61, Print), same_screen YES,
XKeysymToKeycode returns keycode: 92
To exit the utility, close the Event Tester window.
If you don't see the second line, or the keycode in the first line is different for you, please tell me what the keycode is, and ignore the remainder of this post, as your keyboard is probably not based on a standard PC keyboard, and this solution may not work for you.
Surprisingly, this bug is not in ROX-Filer, nor is it in the GTK/GDK libraries which are usually well stocked with bugs. This bug is in X -- or, more specifically, the symbols data for the XKB extension to X, and explaining it will require delving into a bit of history.
This bug is related to the fact that IBM added the
Sys Req (System Request) key when they introduced the PC AT in 1984. This keyboard for the PC AT still had the
* /
PrtSc key on the keypad, as did the previous PC XT keyboard. When IBM introduced enhanced keyboards in 1985 with 101 or more keys, they removed
PrtSc from the keypad's
* key and gave that function its own key, now called
Print Screen. At the same time, they eliminated the dedicated
Sys Req key and piggy-backed that function on the new
Print Screen key. The System Request function could be accessed by pressing
Alt+
Print Screen.
Normally, each key has only one scan code, and the desired function is determined by testing the state of the modifier keys (like the
A key provides 'a' and
Shift+
A provides 'A'). But since the Print Screen and System Request functions were previously on separate keys, the new key sends one scan code for the Print Screen function, and another for the System Request function, thus allowing for backward compatibility with old software.
XKB converts the scan codes to its own keycodes. So originally the
Print Screen /
SysReq key would send different keycodes depending upon whether or not
Alt is pressed (111 for Print Screen (no
Alt) or 92 for System Request (with
Alt) ).
Unfortunately, many of X's functions expect only one keycode for each key on the keyboard. The XKeycodeToKeysym() and XKeysymToKeycode() functions are two of them. ROX-Filer uses these two functions when setting and acting on keyboard shortcuts.
When ROX-Filer prompts you to "Press the desired shortcut . . .", it takes the keycode sent when you press the key, and passes it to the XKeycodeToKeysym() function, which returns the keysym, then calls XKeysymToString() to convert the keysym to a string -- in this case it is "Print". ROX-Filer then adds 'shortcut="Print"' to the icon's definition in the pinboard definition file (normally /root/Choices/ROX-Filer/PuppyPin).
So far, this is good.
But when ROX-Filer later reads the pinboard definition file it calls the other function, XKeysymToKeycode(). Perhaps you noticed when you ran xev that the keycode for the
Print Screen key was 111, and the keysym was "Print", but it reports that "XKeysymToKeycode returns keycode: 92", when it should return 111. The same thing happens when ROX-Filer calls XKeysymToKeycode(), so it is looking for keycode 92 when it should be looking for keycode 111.
That, of course, is not good.
Most keys have multiple keysyms associated with them, such as "a" and "A". In this case they are "Print" and "Sys_Req". The XKeycodeToKeysym() function looks at the XKB data and finds a single keysym that may be used to identify the key (as is done by ROX-Filer). That keysym is always the level-1 keysym -- that is, it is the keysym that corresponds to the key when no modifiers like, for instance, Shift or Alt are active. In this case since the keycode is 111, it will find "Print".
Likewise, the reverse function, XKeysymToKeycode(), will look through an XKB data table and find the keycode for the definition that uses the given keysym for the level-1 (un-shifted) keysym.
So we would expect that, since the keysym is "Print", it will find keycode 111, since "Print" is the level-1 keysym in the definition for keycode 111.
But something is wrong.
Remember that the same key can also return another scan code if
Alt is pressed. Because of that there is another definition for this key in the XKB data. It also has "Print" as the level-1 keysym. The corresponding keycode is 92.
Here is how the definitions look in the /etc/X11/xkb/symbols/pc/pc file:
Code: Select all
key <PRSC> {
type= "PC_SYSRQ",
symbols[Group1]= [ Print, Sys_Req ]
};
key <SYRQ> {
type= "PC_SYSRQ",
symbols[Group1]= [ Print, Sys_Req ]
};
And here is how the keycodes are defined in the /etc/X11/xkb/keycodes/xfree86 file:
XKeysymToKeycode() can only return one keycode. Which does it return? 111 or 92? It has no way of knowing in this case if "Print" should correspond with 111 or 92. It goes with 92.
The solution is to get rid of the second definition. But how can we do that without eliminating the use of the other keycode? If we choose to keep only the definition for keycode 111, which will solve our problem, won't we loose the ability to work with keycode 92? Won't X then loose the ability to respond when the user presses
Alt+
SysRq?
Luckily, no. I was concerned about that, and investigated further. It turns out that a fellow named Owen Taylor noticed this problem (and a similar problem with the
Pause /
Break key) over eleven years ago. His solution was to make this key behave like other keys by making it appear to generate only one scan code -- the scan code generated when it is pressed without
Alt. He has the X server simply replace the undesired scan code with the desired one. So pressing the key with
Alt will issue keycode 111, just as pressing the key without
Alt does. No X application should ever see keycode 92 now, so the definition for that keycode may be eliminated. If the user wants the System Request function, and so presses the key with
Alt, X recognizes this by looking at the state of the modifiers, just as it does for other keys.
In fact, Mr. Owen had patches to eliminate the definition for keycode 92 (<SYRQ>) from the various symbol files where it was defined. (In the years before definitions for common PC keys were collected into the /etc/X11/xkb/symbols/pc/pc file, the definitions were scattered over many files.)
Although Mr. Owen's patch was applied to the X server on 2002-Dec-17, and released in XFree86 4.3.0 on 2003-Feb-27, I can find no evidence, when looking at the sources, to indicate that his other patches were ever applied to the XKB symbol files. Because of that we still have the confusing definition for keycode 92. If all of Mr. Owen's patches had been applied, you would not be reading this long post because the problem would no longer exist.
It is a mystery that the X server patch was applied, but the patches to the XKB symbol files were not. Since those files were in a different branch of XFree86's source tree from the X server (they were filed with the xkbcomp program), perhaps they simply got lost and never made it to the right person. Or perhaps in those days before the PC-specific stuff was given its own files, the patches may have caused problems with non-PC keyboards.
In December 2005 this bug was reported to Red Hat, in January 2006 Ray Strode found the solution (same as Owen Taylor's 2002 solution), and in February 2006 Mike A Harris made a patch for Red Hat and also submitted it and a bug report upstream to Xorg. The folks at Xorg ignored his report and patch for over six months, then Mr. Harris surprisingly closed his own bug report because he was "Not interested in tracking this anymore..." So the bug remains unfixed.
[UPDATE, 2013-Aug-27:
Well, I was wrong about the bug not being fixed. Actually, although never fixed at xfree86.org, it appears to have been fixed and broken again at X.org and later fixed again at freedesktop.org. For details see my 2013-Aug-27 post further down this thread.]
OK, enough history, let's move on to the solution.
Edit the /etc/X11/xkb/symbols/pc/pc file by commenting-out the second definition that has "Print", so that instead of the definitions shown above you have this:
Code: Select all
key <PRSC> {
type= "PC_SYSRQ",
symbols[Group1]= [ Print, Sys_Req ]
};
// key <SYRQ> {
// type= "PC_SYSRQ",
// symbols[Group1]= [ Print, Sys_Req ]
// };
(Alternatively you can, of course, delete those four lines.)
(If you use the Japanese keyboard layout for a PC keyboard, you might have to make two similar edits in the /etc/X11/xkb/symbols/pc/jp file.)
Then execute the following four commands:
Code: Select all
rm /var/lib/xkb/server-*.xkm
setxkbmap
killall ROX-Filer
rox -p /root/Choices/ROX-Filer/PuppyPin
The first command removes your cached keymaps. If you didn't do that, the second command, which reloads your current keymap may just grab the old cache file (and so ignore the file that you just edited) instead of rebuilding the keymap using the edited file. Some Puppies (e.g. Racy 5.2.2) don't use these cache files, so the first command is unnecessary. But it won't hurt, so use it if in doubt. In that case, just ignore the "No such file or directory" error message, if any.
The third and fourth commands restart ROX-Filer so that it will now look for the correct keycode.
That's it.
References - - -
E-mail from Owen Taylor to XFree86 mailing list announcing intentions to submit a patch (2002-Jul-03):
[Xpert]PrintScreen/SysRq and Pause/Break
E-mail from Owen Taylor to XFree86 mailing list containing the the patch itself (2002-Jul-08):
Re: [Xpert]PrintScreen/SysRq and Pause/Break
Bug report from Owen Taylor to Red Hat Bugzilla:
Bug 69743 - Fix SysRq / Print Screen
Reported: 2002-07-24 17:55 EDT by Owen Taylor
Owen Taylor's patch applied at XFree86 to
/xc/programs/Xserver/hw/xfree86/common/xf86Events.c
version 3.140, 2002/12/17 04:45:48 UTC:
CVS log for xc/programs/Xserver/hw/xfree86/common/xf86Events.c
xc/programs/Xserver/hw/xfree86/common/xf86Events.c - view - 3.140
Patch caused a bug in non-PC keyboards, so code was moved to another position in the file by Ivan Pascal in
/xc/programs/Xserver/hw/xfree86/common/xf86Events.c
version 3.147, 2003/03/06 17:39:34:
CVS log for xc/programs/Xserver/hw/xfree86/common/xf86Events.c
xc/programs/Xserver/hw/xfree86/common/xf86Events.c - view - 3.147
Bug report from Matthew Galgoci to Red Hat Bugzilla:
Bug 175661 - metacity global keybindings can no longer use the "Print" keysym
Reported: 2005-12-13 13:46 EST by Matthew Galgoci
Bug report and patch from Mike A. Harris to freedesktop.org Bugzilla:
Bug 5848 - xkbdata - metacity keybindings can no longer use the "Print" keysym
Reported: 2006-02-10 03:17 UTC by Mike A. Harris
[EDITED 2013-Aug-27 to add today's green update.]