Bug 110933

Description of problem:

Note: The following problem has been entered in rhn as service
request 274127 and is now entered in bugzilla upon request of
the Red Hat support engineer in charge of the rhn request.

This report describes a keyboard problem with XFree86 4.3 on
Red Hat Entreprise Linux 3 ES. The AltGr key of French keyboards
is inoperative with some X11 clients (from VMS systems in our case).

This problem did not exist with Red Hat Linux 5.1 to 8.0 on
the same machine.

The machine is a Compaq Deskpro EN with a French keyboard
(PC-type, 105 keys). On these keyboards, characters like
~#{[|`\^@]} are accessed using a combination of the AltGr
key and the top row keys. The AltGr key is located immediately
on the right of the space bar.

Example: the key "0" gives: 
key alone => "à" 
Shift + key => "0" 
AltGr + key => "@" 
 
The Linux system is used as X11 display server for many clients,
including terminal emulator clients from Solaris and VMS. 
 
With local X11 clients (KDE konsole for instance) and Solaris clients
(dtterm  or xterm), the AltGr key works as expected and I get the
~#{[|`\^@]} characters. 
 
On the other hand, with VMS client (DECterm terminal emulator or any
other DECwindows clients), the AltGr key is inoperative. This means
that AltGr+key gives the same result as the key alone. As a consequence,
the following characters, which are quite essential, are not accessible:
~#{[|`\^@]} 
 
I have seen some similar problem reports using Google but no rational 
explanation and no real solution. These problems were related to 
XFree86 4.3 on either RHL 9 or Cygwin environment. Similar problems
were reported with HP-UX clients such as xterm but I have no such
system here to check if this is the same problem.

To illustrate the problem, here are some examples using xev. 
The test is press AltGr+0 (should give the at-sign "@" character).

Local (Linux) xev client, display on Linux X11 server
-----------------------------------------------------
KeyPress event, serial 25, synthetic NO, window 0x2c00001,
    root 0x40, subw 0x2c00002, time 77071927, (47,39), root:(53,569),
    state 0x10, keycode 113 (keysym 0xfe03, ISO_Level3_Shift),
same_screen YES,
    XLookupString gives 0 bytes:  ""

KeyPress event, serial 25, synthetic NO, window 0x2c00001,
    root 0x40, subw 0x2c00002, time 77072247, (47,39), root:(53,569),
    state 0x90, keycode 19 (keysym 0x40, at), same_screen YES,
    XLookupString gives 1 bytes:  "@"

KeyRelease event, serial 25, synthetic NO, window 0x2c00001,
    root 0x40, subw 0x2c00002, time 77072498, (47,39), root:(53,569),
    state 0x90, keycode 19 (keysym 0x40, at), same_screen YES,
    XLookupString gives 1 bytes:  "@"

KeyRelease event, serial 25, synthetic NO, window 0x2c00001,
    root 0x40, subw 0x2c00002, time 77072833, (47,39), root:(53,569),
    state 0x90, keycode 113 (keysym 0xfe03, ISO_Level3_Shift),
same_screen YES,
    XLookupString gives 0 bytes:  ""

As you can see, the result is fine and the xev client receives a
"@" character.

OpenVMS xev client, display on Linux X11 server
-----------------------------------------------
KeyPress event, serial 21, synthetic NO, window 0x2c00001,
    root 0x40, subw 0x0, time 77162034, (164,27), root:(170,557),
    state 0x10, keycode 113 (keysym 0xfe03, (no name)), same_screen YES,
    XLookupString gives 0 characters:  ""

KeyPress event, serial 23, synthetic NO, window 0x2c00001,
    root 0x40, subw 0x0, time 77162519, (164,27), root:(170,557),
    state 0x90, keycode 19 (keysym 0xe0, agrave), same_screen YES,
    XLookupString gives 1 characters:  "à"

KeyRelease event, serial 23, synthetic NO, window 0x2c00001,
    root 0x40, subw 0x0, time 77162893, (164,27), root:(170,557),
    state 0x90, keycode 19 (keysym 0xe0, agrave), same_screen YES,
    XLookupString gives 1 characters:  "à"

KeyRelease event, serial 23, synthetic NO, window 0x2c00001,
    root 0x40, subw 0x0, time 77163230, (164,27), root:(170,557),
    state 0x90, keycode 113 (keysym 0xfe03, (no name)), same_screen YES,
    XLookupString gives 0 characters:  ""

Here, the xev client receives "à" (the primary character of the key).
Differences are:
- On AltGr key events:
  Linux client: state 0x10, keycode 113 (keysym 0xfe03, ISO_Level3_Shift)
  VMS client:   state 0x10, keycode 113 (keysym 0xfe03, (no name))
- On "0" key event, with AltGr down;
  Linux client: state 0x90, keycode 19 (keysym 0x40, at)
  VMS client:   state 0x90, keycode 19 (keysym 0xe0, agrave)

Another example using xmodmap
-----------------------------
In both cases, the X11 server is the one running on Linux.
Using Linux client:

$ xmodmap -pm
xmodmap:  up to 2 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x73),  Super_R (0x74)
mod5        ISO_Level3_Shift (0x71)

$ xmodmap -pk
....
    113         0xfe03 (ISO_Level3_Shift)       0xff20 (Multi_key)
....

Using VMS client:

$ xmodmap -pm -display penguin:0
xmodmap:  up to 2 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x73),  Super_R (0x74)
mod5        BadKey (0x71)

$ xmodmap -pk -display penguin:0
....
    113         0xfe03 (no name)        0xff20 (Multi_key)
....

The differences are:
- Linux client: mod5  ISO_Level3_Shift (0x71)
- VMS client:   mod5  BadKey (0x71)

- Linux client: 113   0xfe03 (ISO_Level3_Shift)  0xff20 (Multi_key)
- VMS client:   113   0xfe03 (no name)           0xff20 (Multi_key)

Version-Release number of selected component (if applicable):
XFree86-4.3.0-35.EL

How reproducible:
Always

Steps to Reproduce:
1. Use a Linux system with X11 server and French keyboard
2. Run a X11 client (terminal emulator for instance) on a VMS system,
using the Linux system as display server
3. Press keys AltGr+0
  
Actual results:
Got character "à"

Expected results:
Should get character "@"

Additional info: