When changing the xkb settings with:

  xkbcomp -w0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY

not all these settings are taken into account by some running
X applications (or worse, see below). New X applications (i.e.
those started after running the above command) are not affected.

At least the following ones are affected, from a test I've just done:
fvwm, xterm, rxvt-unicode, mlterm, and xev. Since all of them directly
depend on libx11-6, I suppose the bug is there (another reason given
below). More precisely:
  * With fvwm, Ctrl-Meta-arrows have no effect.
  * With the terminals, Alt-arrows have the same effect as without Alt,
    contrary to my settings. A running gnome-terminal is not affected,
    i.e. after running the xkbcomp command (it is needed), everything
    is fine with it.
  * With xev, Ctrl-Meta-arrows seem to return the same information as
    before pluging out and in the USB keyboard. But I can see that it
    is affected with the Alt-arrows.

The above xkbcomp command is needed because of bug 633849 (XKB settings
lost after suspend (hibernate) / resume or USB keyboard plugged in),
which affects all X applications (old and new), which is not surprising
since they are consistant with what xev says.

I've also done the following test:
1. ssh -Y to a remote machine (PowerPC). This remote machine also has
   libx11-6 2:1.4.4-4, and xterm 276-2.
2. I run xterm on this remote machine from this ssh session (thus with
   local display). I can see that Alt-Up has the expected effect.
3. On the local machine (where the X server is running), I plug out
   the USB keyboard, then plug it in again.
4. On the remote xterm, Alt-Up doesn't have the expected effect,
   but that's just because of bug 633849.
5. On the local machine (X server), I run the xkbcomp command.
6. On the remote xterm, I type Alt-Up. Result: xterm segfaults.

The backtrace shows, after installing libx11-6-dbg and redoing the
test:

Core was generated by `/usr/bin/xterm -xrm *printFileOnXError: /home/lefevre/private/xterm-saved-13302'.
Program terminated with signal 11, Segmentation fault.
#0  XkbTranslateKeyCode (xkb=0x1009c670, key=<optimized out>, mods=128,
    mods_rtrn=0xbf956690, keysym_rtrn=0xbf9566c8)
    at ../../../src/xkb/XKBBind.c:314
314     ../../../src/xkb/XKBBind.c: No such file or directory.
        in ../../../src/xkb/XKBBind.c
(gdb) bt
#0  XkbTranslateKeyCode (xkb=0x1009c670, key=<optimized out>, mods=128,
    mods_rtrn=0xbf956690, keysym_rtrn=0xbf9566c8)
    at ../../../src/xkb/XKBBind.c:314
#1  0x0fc3a7f0 in XkbLookupKeySym (dpy=0x10073370, key=<optimized out>,
    mods=128, mods_rtrn=<optimized out>, keysym_rtrn=<optimized out>)
    at ../../../src/xkb/XKBBind.c:259
#2  0x0fc3bbcc in XLookupString (event=0xbf95684c, buffer=0xfce8fd8 "",
    nbytes=256, keysym=0xbf9566c8, status=<optimized out>)
    at ../../../src/xkb/XKBBind.c:665
#3  0x0fc12310 in _XimLocalFilter (d=0x10073370, w=<optimized out>,
    ev=0xbf95684c, client_data=0x1009c108 "\017\316|<\020\tqp")
    at ../../../../modules/im/ximcp/imLcFlt.c:53
#4  0x0fbbf098 in XFilterEvent (ev=0xbf95684c, window=<optimized out>)
    at ../../src/FilterEv.c:97
#5  0x0fb04768 in ?? () from /usr/lib/powerpc-linux-gnu/libXt.so.6
#6  0x0fb04984 in XtDispatchEvent () from /usr/lib/powerpc-linux-gnu/libXt.so.6
#7  0x1002b4e8 in ?? ()
#8  0x100175d0 in ?? ()
#9  0x10017a98 in ?? ()
#10 0x10005ad4 in ?? ()
#11 0x0fd6e7ec in ?? () from /lib/powerpc-linux-gnu/libc.so.6
#12 0x0fd6e9b0 in __libc_start_main () from /lib/powerpc-linux-gnu/libc.so.6
#13 0x00000000 in ?? ()

I forgot to give my XKB config. It is attached.

Control: found -1 2:1.6.2-1
[...]

Still the same problem. I could see it at least with xterm and fvwm.

working, but after a few dozens of seconds (or some particular
event?), they were no longer working.

Control: reassign -1 xterm 320-1

The problem no longer occurs with fvwm, so that this does not seem to
be a libx11-6 issue (or it has been fixed).

xterm is still affected, thus I'm reassigning the bug to it.

This is in relation to the following kernel bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805168

where I got a USB disconnect, so that the keyboard mapping is lost and
I have to remap it with the above command.

Control: found -1 327-2

Actually, not "changing", but "restoring" (so that the settings are
the same as when the application was started).

This now occurs again with fvwm. So, perhaps the problem is
related to application code too.

and still affected with 327-2.

juan carlos aa

The given severity "important" falls short of the guidelines, because this
refers to an event used by few people (your experience may differ).

The given severity "important" falls short of the guidelines, because this
refers to an event used by few people (your experience may differ).

By very few people (due to an unusual USB keyboard), but this is
extremely annoying: each time the USB keyboard is reconnected,
which can occur quite often for a laptop one uses at home and
at work, all the xterms need to be quit and started again.

BTW, it seems that the issue that needs xkb setting change with
this keyboard is now handled at the driver level via the module
option "options hid_apple swap_opt_cmd=1" (actually for quite a
long time, but this was not the case yet when I reported the bug
in 2012... I'll have to try):

https://help.ubuntu.com/community/AppleKeyboard

this wasn't related to this specific Apple keyboard. IIRC,
I got confused just because only USB keyboards are affected
(Debian bug 633849) and because this is the only USB keyboard
I've used in this context. So, with a USB keyboard, I need to
restore the XKB settings, and lv3:lalt_switch is probably what
triggers the issue with xterm.

So this bug should affect any xterm user who
  * has a USB keyboard that is not permanently plugged in;
  * uses an XKB option like lv3:lalt_switch;
  * restores the XKB settings due to Debian bug 633849; for this
    one, other users have complained in the upstream bug:
https://gitlab.freedesktop.org/xorg/xserver/-/work_items/266

Note: I have not tested for a long time since with my current
laptop, I systematically switch it off when I need to connect
it to the dock (where the USB keyboard is connected) due to a
kernel bug.