*** Bug 8584 has been marked as a duplicate of this bug. ***

I have the same problem, so I report what I have found hoping it might be any help.

I am using JP106 keyboards, and have been mapping <AB11> (backslash/underscore keycode=211) to Shift_R by xmodmap.  Then, the key worked as a Shift modifier on Debian Etch (and olders), but does not work on Ubuntu 7.10 nor on Ubuntu 8.4.  It seems it is because the key release event for keycode=211 is produced immediately after the key press event is produced even if I hold down the key and do not release.  For example, if I press <AB11> -> press "z" -> release "z" -> release <AB11>, then xev says:

KeyPress event, serial 30, synthetic NO, window 0x3600001,
    root 0x80, subw 0x0, time 2808272285, (156,133), root:(161,181),
    state 0x0, keycode 211 (keysym 0x5c, backslash), same_screen YES,
    XKeysymToKeycode returns keycode: 51
    XLookupString gives 1 bytes: (5c) "\"
    XmbLookupString gives 1 bytes: (5c) "\"
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3600001,
    root 0x80, subw 0x0, time 2808272285, (156,133), root:(161,181),
    state 0x0, keycode 211 (keysym 0x5c, backslash), same_screen YES,
    XKeysymToKeycode returns keycode: 51
    XLookupString gives 1 bytes: (5c) "\"
    XFilterEvent returns: False

KeyPress event, serial 30, synthetic NO, window 0x3600001,
    root 0x80, subw 0x0, time 2808272679, (156,133), root:(161,181),
    state 0x0, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (7a) "z"
    XmbLookupString gives 1 bytes: (7a) "z"
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3600001,
    root 0x80, subw 0x0, time 2808273058, (156,133), root:(161,181),
    state 0x0, keycode 52 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (7a) "z"
    XFilterEvent returns: False

On the other hand, if I press, say "/", press "z", release "z", release "/", xev correctly says: KeyPress "/" -> KeyPress "z" -> KeyRelease "z" -> KeyRelease "/".

It seems the following three keys on JP106 keyboards have the same behavior:

<AB11> keycode=211
<HKTG> keycode=208
<PAUS> keycode=110 (less than 128...? because of some other reason?)

First, I thought it must be related to key type configuration in XKB JP106 layout, so I edited the following two lines in xkb/keycode/xfree86:

    <RTSH> =  62;
           :
           :
    <AB11> =   211;             // backslash/underscore

to:

    <AB11> =  62;
           :
           :
    <RTSH> =   211;             // backslash/underscore

and rebooted.  Then, keymap was changed correctly, but the behavior of KeyRelease event for the key 211 did not change.

Other things I found:

1. On the console, key press/release event for the key 211 is normal.  I tested it with showkey command.
2. On X, the behavior above happens even with twm, so gnome does not seem related.
3. It happens both with the keyboard on a laptop and a USB connected keyboard, so probably not a hardware problem.

Are those findings of any help?  If there is anything I can do to provide more information, please let me know. This is a quite serious problem for me because I cannot map <AB11> "the key at the position where the shift key should be" to the shift key!!

Here is a probably related bug, with a possible workaround :

The idea is to bind some keys to perform automatically CTRL+C/V/X/Z.

Let's say that I have the following mapping (the >127 keycode change nothing for the base key) in xkb_symbols:

    key <I73> { [ v ] };

I now want to do something like :

    key <I7C> { actions[group1] = [ Redirect(keycode=<I73>, modifiers=Control) ] };      // ctrl-v


But this does not work and results in :

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  150 (XKEYBOARD)
  Minor opcode of failed request:  9 (XkbSetMap)
  Value in failed request:  0x23fa0001
  Serial number of failed request:  107
  Current serial number in output stream:  113


However if I use a < 127 keycode for the redirection, this works :

    key <FK15> { actions[group1] = [ Redirect(keycode=<I73>, modifiers=Control) ] };      // ctrl-v


Here is now the promised workaround. In the xkb_compatibility section, interpret an unused symbol:

    interpret F33 {
        action = Redirect(Key=<I73>, modifiers=Control);
    };

Then in the xkb_symbols section, there is no need for the redirect anymore :

    key <I7C> { [ F33 ] };      // ctrl-v

Now this works, even for this > 127 keycode.


Both the <127 keycode and the workaround solution work when additionnally used as overlay (hence double-indirection):

    key <AB04> {
        // key definition here: type[group1] = ..., [...]
        overlay1 = <I7C>
    };
 
This works with overlay1 = <I7C> using the workaround, or with overlay1 = <FK15> for the <127 solution.


Hope this helps,

Nicolas Brodu

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/issues/7.