print key not recognized

Please post any bugs you have found
Post Reply
Message
Author
xmf-149
Posts: 23
Joined: Fri 02 Aug 2013, 04:00

print key not recognized

#1 Post by xmf-149 »

i have the following item on the pinboard. the print screen key is not recognized
every other key works. does anyone know where to look to find out why?
Attachments
Edit_Item.png
(18.38 KiB) Downloaded 936 times
:!: :!: :!:

User avatar
L18L
Posts: 3479
Joined: Sat 19 Jun 2010, 18:56
Location: www.eussenheim.de/

Re: print key not recognized

#2 Post by L18L »

xmf-149 wrote:i have the following item on the pinboard.
I have changed
/usr/bin/mtpaint
to
/usr/bin/mtpaintsnapshot.sh
and

deleted the line
<Key keycode="111">exec:tas</Key>
in my $HOME/.jwm/jwmrc-personal

... and click on icon launches mtPaint Snapshot

Hope that helps
:D

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#3 Post by npierce »

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:

Code: Select all

xev
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:

Code: Select all

    <PRSC> = 111;
    <SYRQ> =  92;
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.]
Last edited by npierce on Tue 27 Aug 2013, 18:53, edited 1 time in total.

xmf-149
Posts: 23
Joined: Fri 02 Aug 2013, 04:00

#4 Post by xmf-149 »

thanks for the info
i have elected to use a jwmrc-personal key binding instead of an icon unless this would be fixed by Xorg
:!: :!: :!:

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#5 Post by npierce »

You're welcome.

Yes, specifying the 111 keycode in jwmrc-personal does avoid the problem of XKeysymToKeycode() returning the wrong keycode.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#6 Post by npierce »

(xmf-149, I realize that you have successfully worked-around this problem. So this post is directed to anyone who would like to fix the XKB problem so that the Print Screen key works with ROX-Filer or other applications.)

I looked into this a bit more, prior to reopening the 2006 bug report mentioned in my first post.

It turns out that I was wrong about this bug not being fixed. It was fixed by X.org, but broken again. Later it was fixed again at freedesktop.org.

Here is what I can piece together:

At one time both xfree86.org and X.org maintained XKB data in their own CVS repositories. This required folks submitting fixes and enhancements to submit them to both organisations. When submissions were made to only one of the repositories, the repositories were no longer in sync with each other. In 2004, to avoid this and other problems, freedesktop.org created a new central repository called "xkeyboard-config".

Although there is no sign of this bug ever being fixed by the XFree86 folks back in the days when they maintained the XKB data (the latest version of the symbols/pc/pc file in their CVS repository, dated 2003-Aug-22, still has the bug), when X.org took over they apparently fixed the bug because the fix was included in their release of X11R6.8.1. In fact, I think Puppy once had X11R6.8.1, but Puppy 2.10+ was upgraded to X11R7.0 around December 2006. At that time Dougal fixed some issues with the files, and most of these files haven't changed in Puppy since then.

Unfortunately, X11R7.0 had the bug again, so it is still in the symbols/pc/pc file which hasn't changed in Puppy since 2006.

If the bug was fixed in X11R6.8.1, why wasn't the fix still in X11R7.0? Good question. I've not been able to locate the X.org xkbdata CVS that was in use back then (perhaps it no longer exists), so I don't know for sure what happened, but that was around the same time that X.org deprecated their own XKB data in favor of freedesktop.org's xkeyboard-config repository.

So this is probably what happened: That new repository appears to have been based upon the xfree86.org repository, which still had the bug. The bug fix wasn't committed in the new repository until 2005-Aug-11, probably after X.org grabbed the data for X11R7.0.

Anyway, since XKB data in Puppy apparently is maintained locally, I am attaching a file which corrects both this Print Screen bug and a similar bug for the Break key. After downloading and decompressing, it should be moved to the /etc/X11/xkb/symbols/pc/ directory, replacing the pc file already there.


References - - -

Bug report and patch from Mike A. Harris to freedesktop.org Bugzilla:
Bug 847 - [PATCH] XKB - print-screen key is broken in certain keyboard layouts
Reported: 2004-07-09 13:55 UTC by Mike A. Harris

Commit that fixes above bug, 2005-08-11:
xkeyboard-config - XKB data.: fixing #847
Attachments
pc.gz
Corrected XKB data file for common PC keyboard symbols
(1.81 KiB) Downloaded 427 times

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#7 Post by miriam »

Thank you npierce for this treasure trove of information. I am rapt that I now finally understand how this works, and why it didn't, and what I needed to do to fix it.
Wonderful!
[color=blue]A life! Cool! Where can I download one of those from?[/color]

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#8 Post by npierce »

You're welcome. I am pleased to know that someone was actually able to slog through one of the windiest of my long-winded posts, that you found a "treasure trove of information" in it, and that it helped you to understand and fix the problem. I'll admit that I sometimes find the need to study the history of an issue fairly deeply in order to fully understand it. While I suspect that that level of detail can probably be fairly boring to some folks, I am glad that it is sometimes enlightening to others.

Thanks for saying so.

Post Reply