Bug 110933 - AltGr key not working for some X11 clients
AltGr key not working for some X11 clients
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: XFree86 (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-25 12:32 EST by Thierry Lelegard
Modified: 2007-11-30 17:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-08 14:04:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Thierry Lelegard 2003-11-25 12:32:02 EST
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:
Comment 1 Pierre Amadio 2003-12-02 09:01:22 EST
I experience the same trouble with a Xserver on RHEL3 and a xterm
hosted on a HP-UX B.11.00 .

playing with XKeyCaps with the correct keyboard (105 fr) show that the
correct key are supposed to be mapped to their respective position
(mod3 backslash) but altgr8 still behave as if only 8 has been activated.

Furthermore, even if the map shown by XKeyCaps is exactly what i have
on the keyboard, some keys does not behave correctly: pressing the 2
key (0x0B) in order to have a eacute just put 'C)' on the screen.
egrave gives 'C('
ugrave gives 'C9' and so on.
Comment 2 Thierry Lelegard 2004-01-13 12:27:07 EST
I have finally found a workaround.

Note that this is NOT a proper solution, just a workaround for
an XFree86 bug which NEEDS TO BE FIXED ANYWAY.

The following xmodmap definitions map both ISO_Level3_Shift and
Mode_switch
to the AltGr key. Then, all keys with an AltGr value must be remapped with
the same interpretation with different modifiers (since X11 clients will
see the AltGr key as different modifiers, depending on the platform).

!----------------------------------------------------------------------------
! Keyboard mapping for:
!   - XFree86 4.3 X11 server
!   - OpenVMS X11 clients (possibly also useful for HP-UX and AIX)
!   - French PC keyboards
!----------------------------------------------------------------------------

! Definition of AltGr key (right of space bar):
!   - ISO_Level3_Shift is the default value (XFree86 4.3) and is used by
!     Linux and Solaris clients.
!   - Mode_switch is used by OpenVMS clients

keycode 113 = ISO_Level3_Shift Mode_switch

! Keys with third value using AltGr key.
!   - First two values are default values.
!   - Third value is used by OpenVMS clients.
!   - Fifth value is used by Linux & Solaris clients.

keycode  11  =  eacute      2         asciitilde    asciitilde   
asciitilde
keycode  12  =  quotedbl    3         numbersign    numbersign   
numbersign
keycode  13  =  apostrophe  4         braceleft     braceleft    
braceleft
keycode  14  =  parenleft   5         bracketleft   bracketleft  
bracketleft
keycode  15  =  minus       6         bar           bar           bar
keycode  16  =  egrave      7         grave         grave         grave
keycode  17  =  underscore  8         backslash     backslash    
backslash
keycode  18  =  ccedilla    9         asciicircum   asciicircum  
asciicircum
keycode  19  =  agrave      0         at            at            at
keycode  20  =  parenright  degree    bracketright  bracketright 
bracketright
keycode  21  =  equal       plus      braceright    braceright   
braceright
keycode  26  =  e           E         EuroSign      EuroSign      EuroSign
keycode  35  =  dollar      sterling  currency      currency      currency

!----------------------------------------------------------------------------

Important: This mapping works for French keyboards only. Other
international
keyboards with AltGr must use appropriage mappings. 

Guidelines for building other mapping for other keyboards:

  1) Save original mapping (xmodmap -pke >xmodmap.txt)

  2) Create a new mapping file (xmodmap.vms for instance). Add the
following
     line at the beginning: keycode 113 = ISO_Level3_Shift Mode_switch

  3) Use xev from a "working" client (Linux for instance)

  4) In xev, press AltGr+key for every key with an AltGr value.
     Example on a French keyboard:

KeyPress event, serial 25, synthetic NO, window 0x2c00001,
    root 0x40, subw 0x0, time 6109189, (141,92), root:(147,138),
    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 0x0, time 6110049, (141,92), root:(147,138),
    state 0x90, keycode 19 (keysym 0x40, at), same_screen YES,
    XLookupString gives 1 bytes:  "@"

  5) In the above example, keycode 19 produces keysym "@", named "at" with
     modifier ISO_Level3_Shift (AltGr).

  6) In the original mapping xmodmap.txt, get keycode 19. Example (French
     keyboard): keycode 19 = agrave 0

  7) Add the AltGr value three times and add the new line in the new
mapping
     file xmodmap.vms. Example: keycode 19 = agrave 0 at at at

  8) Repeat the process for all keys with an AltGr value.

  9) In the session init file, run the following command:
     xmodmap xmodmap.vms

AGAIN, THIS IS ONLY A WORKAROUND, ASK FOR A PROPER FIX IN XFREE86 !
Comment 5 Thomas Specht 2004-05-28 08:50:23 EDT
I encountered the same problem with RHEL3 using a german keyboard.
This problem only exists, if I'm using gnome - there is no problem
with kde. 
Comment 6 Bastien Nocera 2004-06-03 09:24:33 EDT
Adapted from Ezio:
"
AltGr is mapped as Mode_switch in RHEL 2.1 and it is mapped as
ISO_Level3_Shift in RHEL 3.

When AltGr+Key is pressed, an event with the correct keysym is
generated by both versions, but:

state = 0x2000 in RHEL 2.1
state = 0x0080 in RHEL 3

It appears that some (broken) applications are sensitive to these
values and ignore the KeyUp/KeyDown event sent by a RHEL 3 X server.

Unfortunately the real solution is fixing the broken application, in
the meantime you can obtain a keymap from a RHEL 2.1 machine w/ French
(German, etc.) keyboard like this:

xmodmap -pm
xmodmap -pke

The output of xmodmap -pke should be parsable by "xmodmap -e" on the
target hosts.
"
Comment 8 John Dennis 2005-07-08 12:21:59 EDT
clearing out old bug reports, this shouldn't be assigned to me any longer.
Comment 9 Kevin E. Martin 2005-07-08 14:04:44 EDT
Corresponding issue tracker was closed.
Closing this one as suggested.

Note You need to log in before you can comment on or make changes to this bug.