Moving from comment #8 of bug 3725. When pressing AltGr on the client, it should typically send ISO_Level3_Shift over VNC. In debug mode, this can be viewed as: Viewport: Key pressed: 0xfe03 (0xfe03) '' => 0xfe03 During testing of bug 3725, I had a case where Alt_R was sent instead: Viewport: Key pressed: 0xffea (0xffea) '' => 0xffea xev however correctly gave ISO_Level3_Shift: KeyPress event, serial 33, synthetic NO, window 0x4400001, root 0xb0, subw 0x0, time 5581540, (1171,618), root:(1177,672), state 0x2010, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 124 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x4400001, root 0xb0, subw 0x0, time 5581596, (1171,618), root:(1177,672), state 0x2090, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 124 XLookupString gives 0 bytes: XFilterEvent returns: False The factor that caused this problem was that two XKB layouts were defined: USA and Sweden. The last one was active. One can see this due to the strange state of 0x2090. Also note the output from xmodmap -pke: keycode 113 = Alt_R Meta_R ISO_Level3_Shift Also, here's how the xmodmap looked like: shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Alt_R (0x71), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 Down (0x68) mod4 Super_L (0x73), Super_R (0x74), Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x8), ISO_Level3_Shift (0x7c) It is possible to work around this problem either by only using one client side layout at a time, or making sure that the active layout is the first one. However, we should see that vncviewer does wrong in this case; it should really produce ISO_Level3_Shift, just as xev does.
Created attachment 476 [details] us_swe.xkb