Subject: Re: Notification: incoming/852

From: Dan Espen <[email-masked]>
Date: Fri, 08 Feb 2002 13:00:00 -0500

This reply is from Dominik Vogt, because of mail system problems,
the reply appears to come from me.  If you'd like to reply,
reply to fvwm-workers.

On Thu, Feb 07, 2002 at 06:34:02AM -0600, fvwm-bug wrote:
> FVWM Bug Tracking notification
> 
> new message incoming/852
> 
> Full_Name: Stanislav Meduna
> Version: 2.2.5
> CVS_Date: 
> OS: Red Hat Linux 7.2
> X_Server: XFree86 4.1.0
> Submission from: (NULL) (212.88.180.5)
> 
> 
> There are keyboards that provide special keys such as Power, WakeUp or
> Standby. These keys return special keycodes that can be mapped to the
> keysyms XF86PowerOff, XF86Standby, XF86WakeUp - see e.g. the XKB
> definitions in /usr/X11R6/lib/X11/xkb/symbols/inet.
> 
> I did this mapping and I see the keysyms returned correctly when watching
> them with xev. They are not mentioned in keysyms.h, but the XStringToKeysym
> function also recognizes names such as XF86PowerOff and returns the
> corresponding keysym.
> 
> I would now like to hook some actions to these keys. Unfortunately the fvwm
> does not seem to recognize these keysyms and my bindings are ignored.

On my system, the XStringToKeysym() function does indeed return
the proper keysym value, but then XKeysymToKeycode returns zero.
I don't know if it's the same problem on your system.  Try

  $ xmodmap -pke

and check if the KeySym is actually assigned to a keycode.  If
not, you have to use xmodmap to assign these keys to a keycode.

> I am able to do this in the sawfish wm and I am successfully using other
> keybindings in the fvwm, so I think that the problem is really in the fvwm.

> The keysyms are a bit special in that they have the highest two bytes
> non-null. My uneducated guess is that the keysym values get stripped to 16
> bits somewhere.

No, that's not the problem.  Fvwm uses the KeySym and KeyCode
types defined by the X headers everywhere.

Bye

Dominik ^_^  ^_^

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214             E-mail: [email-masked]
Piscataway, NJ 08854                       Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: "Stanislav Meduna" <[email-masked]>
Date: Fri, 8 Feb 2002 20:44:45 +0100

Hello,

> I don't know if it's the same problem on your system.

No, it isn't - the following program:

=== snip ===
#include <X11/Xlib.h>
#include <stdio.h>

main()
{
  Display *d = XOpenDisplay(":0.0");
  KeySym ks = XStringToKeysym("XF86PowerOff");
  KeyCode kc = XKeysymToKeycode(d, ks);

  printf("%x, %d\n", ks, kc);

  XCloseDisplay(d);
}
=== snip ===

produces:
1008ff2a, 222

> Try
> 
>   $ xmodmap -pke
> 
> and check if the KeySym is actually assigned to a keycode.

Yes it is:

keycode 221 =
keycode 222 = XF86PowerOff
keycode 223 = XF86Standby
keycode 224 =
keycode 225 =
keycode 226 =
keycode 227 = XF86WakeUp

> types defined by the X headers everywhere.

These symbols are _not_ defined in the X headers. That the
XStringToKeysym knows about them is something buried in the
Xlib - the manpage says that this behaviour is implementation
dependent.

I am also using XKB and not the xmodmap mappings (maybe
it matters).

If you cannot reproduce it, I'll try to look into the code
myself and let you know the result - I just hoped you just
look and say "Ahh, this is trivial - just do foo" :-)

Regards
-- 
                              Stano

---

From: Stanislav Meduna <[email-masked]>
Date: Sat, 9 Feb 2002 09:34:20 +0100 (CET)

Hi,

> > That the
> Which man page?

XStringToKeysym and related:

       Standard KeySym names are obtained from <X11/keysymdef.h>
       by removing the XK_ prefix from each name.  KeySyms that
       are not part of the Xlib standard also may be obtained
       with this function.  The set of KeySyms that are available
       in this manner and the mechanisms by which Xlib obtains
       them is implementation-dependent.

>                             If you want to debug this, you should
> start in the files fvwm/bindings.c and libs/Bindings.c.  There, the
> original binding command is processed (starting with Cmd_Key).
> If that works fine, the code handling key presses is in
> fvwm/events.c, HandleKeyPress().

OK, thanks for the hints.

> Finally, I'm on a holiday for two weeks from saturday, so don't
> expect any quick replies from me ;-)

Oh, you don't respond quicker when on the holiday? :-))) Have
a nice holiday and thank you for the work on the fvwm.

Regards
-- 
                                            Stano

---

From: Stanislav Meduna <[email-masked]>
Date: Sat, 9 Feb 2002 13:41:36 +0100 (CET)

Hello,

> start in the files fvwm/bindings.c and libs/Bindings.c.

Umm, you was right - I did not have the keycode mapping - at the
time of fvwm starting, that is :-( My environment starts a keyboard
mapping application, so I see the mapping when running my test
application, but this is of course after fvwm parsed the bindings.

So I know how to solve my problem, but this IMHO revealed another
one. There are environments that use to change the keyboard
mapping on the fly (and not via the keyboard specification
in the X server) - Slovakia (where I live) is one of such regions.
The fvwm binds its keys according to keycodes. So when the
keycode->keysym mapping changes, fvwm does not know about it.
On the slovak keyboard this could mean that Alt-Z on the
local keyboard must be specified as Alt-Y in the fvwm config.

I inspected the code and I don't see any easy solution. While
there is no problem to catch the KeymapNotify event, the user's
specification of the mappings is lost after the parsing and
cannot be reconstructed from the linked list of bindings.
I thought of remembering of the Key commands and replaying
them on the KeymapNotify, but all the possibilities of interaction
using FvwmConsole etc. make this no easy task.

I can live with what I have (I just change the map before the window
manager starts or reissue the "Key" command after each mapping change),
but if you have some idea, how this could be addressed in the fvwm
itself, let me know.

Thanks
-- 
					Stano

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 9 Feb 2002 13:57:27 +0000

> but if you have some idea, how this could be addressed in the fvwm

I would add a menu item or a keybinding (that does not change) to rerun
all needed Key commands.

Or, it is possible to delay some commands in the cvs version:

  # postpone to 1 minute until keyboard mapping is stabilized
  Schedule 60000 Function MyKeyBindings

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 9 Feb 2002 01:29:27 +0100 (MET)

> These symbols are _not_ defined in the X headers.

I mean the data types KyeSym and KeyCode, not the key symbols
themselves.

Which man page?

> look and say "Ahh, this is trivial - just do foo" :-)

Sorry to disappoit you ;-)  If you want to debug this, you should

Bye

Dominik ^_^ ^_^

P.S.: I can't reply to the list at the moment.  Please forward this
mail to [email-masked].  Also, please sent replies to that
list, not to the address I'm writing this from. This is not my usual
mail addres but only a temporary solution.  Finally, I'm on a holiday
for two weeks from saturday, so don't expect any quick replies
from me ;-)

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net